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?

Thanks!

DJM