Re: [Zope] HappySession
Diego Rodrigo Neufert writes: I'm making a site with frames with session management. I'm using HappySession to do it... I need to call SESSION['something'] in various frames at the same time, but when a SESSION expire I got a Transaction Error that blow up my Zserver... Anyone know how to solve this or another SESSION product that doesnt have that problem? I can tell you, that FSSession has the same problem, at least the version before the current one (announced some days ago). I would expect that SQLSession is more robust. But beware, there may well be transaction conflicts, because several threads may try to change the same record in the database. If this indeed happens, than at least one transaction cannot be committed and must be roled back. Dieter ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] HappySession
On Fri, 1 Sep 2000, Dieter Maurer wrote: I can tell you, that FSSession has the same problem, at least the version before the current one (announced some days ago). FSSession has no longer such problem. However you might still loose data if you access the same SessionUID from many frames. I don't thing there is a general solution to the problem without involving read locks which will slow down the whole Zope site. Or raising ConflictErrors which for frame usage like the case you mention will occur very often. The same problem will occur whether you store the Session info in an RDBMs or not. For instance: Thread A reads Session1 Thread B reads Session1 Thread A modifies Session1 and commits Thread B modifies Session1 and commits. This creates a conflict and the solution I have chosen is to keep the last to commit. In general we can achieve very high write rates because there is a natural isolation among requests, one thread per SessionUID. Problems will occur if multiple concurrent requests try to access the same SessionUID. This could occur in situations that employ frames but (at least in our case) most of the time the Session info is required only in one frame. In any case I have tested the latest version of FSSession against multiple frames accessing the same SessionUID and I do not get TransactionErrors. Actually there is a slightly better way but it will involve a lot of complicated programming so I won't even mention it ... :-) Pavlos ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Re: [Zope] HappySession 0.1.0 released!
Hung Jung Lu wrote: I have been using RAM-based session management for a while, but never wrote a product for it. Since Graham Chiu has mentioned it again about making a real product, I have taken the time to make one, and called it HappySession. :) Well, in short, it uses cookie for session id, you specify a maximum session expiration time, and expired session data are automatically deleted. It's Zope-transaction-aware. 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.) -- Itamar S.T. [EMAIL PROTECTED] "It don't get thingier than that!" ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
