[Twisted-web] getSession, componentized but not async?

[Donal McMullan]

I'm curious about request.getSession

Per the docs:
https://twistedmatrix.com/documents/current/web/howto/using-twistedweb.html

It seems like it's tricky to use correctly. My code needs to:
 - define an Interface
 - define a class that implements my Interface
 - call registerAdapter, passing in my class, server.Session and my
Interface
 - get a Session instance
 - brace myself
 - create an instance of my Interface class, passing in the Session instance
 - update that Interface instance.... it will persisted, but only in-memory

By default, that data doesn't go to database/memcached/whatever, so it's
only accessible in-process

On first blush, that seems like a lot of legwork. I'm not clear on what
utility's provided by all this versus say maintaining a dict as a
class-attribute on Site or something. It's also (for me) counter-intuitive
to be creating an instance of an _Interface_ and poking data into it.

Also I was a bit surprised that getSession doesn't return a deferred, since
it seems like it'd be common to want to persist session data in an external
store so that multiple twisted-web processes can access it in a
clustered/load-balanced setup. How do other folks go about that?

I hacked something together a while ago to run session data into Redis, but
what I ended up with required so much surgery on twisted web's classes that
I figured I must be doing it wrong. I think Site, SessionFactory and
Request were all customised.

I was thinking about this again in the context of Cory's "Implement
server-side HTTP/2 server push" ticket:
https://twistedmatrix.com/trac/ticket/8485

In this context, I'd like to have access to my session data in multiple
Resource objects without _necessarily_ having to round-trip to an external
store each time to get/put the same data. In the case of http 1.1 requests,
I guess there's no way around that round-trip, so it might be optimal if my
Resource objects could be oblivious to the underlying protocol version and
Session get/put mechanism.

So it'd be great if the default Session mechanism could take care of me
there, and I could just have my cake and eat it.

Another wrinkle that surprised me when I was hacking on this was that there
didn't seem to be a way to uniquely identify a request instance, so within
the session code it was impossible to tell if two calls to getSession were
coming from different points in the callback chain responding to a single
Request, or if the second belonged to a different Request entirely.

So my confusion is probably apparent at this stage :)

I'm guessing others have been here before me. What approaches have you
taken to storing your sessions? Are there good open source projects that I
should look to for best practice?

Thanks!

DJM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://twistedmatrix.com/pipermail/twisted-web/attachments/20160705/bdbe7717/attachment.html>