From: Itamar Shtull-Trauring <itamar@maxnm.com> I'd be very grateful for a description of how you built the session server in combination with persistence, transactions, and the fact that each thread has it's own copy of data.
If I understood correctly, the references to the server are stored in the class (which I assume is global for all Zope threads.)
I see some worries from, you, ha! Let me explain a little bit to calm down your worries. First of all, let me tell you that the long term plan goes way beyond what the innocent happy face may hide. :) HappySession is aimed at serving multiple copies of Zope running at multiple threads each, and with multiple session servers located at multiple machines! It's not doing that now, but I have laid out things so it can be extended that way. And I have separated client aspects from server aspects in my code, so eventually it can be hooked up to SQL server or File System server, not just RAM server. (1) Persistence: no need to worry about storing garbage in ZODB. No persistence at all for the session data. You are correct, the main session data is stored in the class, which is global to all Zope threads. (2) Transaction: per REQUEST transaction per thread, a copy of the session data pertinent to that particular REQUEST is created as volatile attribute inside the SESSION instance. The updated temporary copy is stored back to the main session data if and only if transaction completes without errors. (3) Thread safety: locking mechanim is in place to prevent simultaneous modification of the main session data dictionary from different threads. All is in the codes. Take a look and you'll see it's not too innocent at all. :) regards, Hung Jung ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com