5 Jul 18:03 2016
getSession, componentized but not async?
Donal McMullan <donal.mcmullan <at> gmail.com>
2016-07-05 16:03:46 GMT
2016-07-05 16:03:46 GMT
I'm curious about request.getSession
Per the docs:
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:
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?
_______________________________________________ Twisted-web mailing list Twisted-web <at> twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web