Hi! I'm still having problems with the sessions. And I am beginning to think that it's not me that is wrong, but the sessioning code has a major conceptial flaw: - I have an index_html method that calls an "initializeSession" method at the beginning to initialize certain session variables. (Is there another way to do this?) - As the new sessioning code seems to be working within the transaction machinery, the SESSION.set action causes the mere display of an index_html page (that includes a session initialization method) to be added to the undo logs - If we use versions at the same time, the index_html method gets locked - After leaving the version, my index_html method causes a version lock error! Strictly speaking, this behaviour might be correct, as the SESSION.set indeed changes stuff. But it just isn't usable like that. How am I supposed to use sessions together with versioning at all if I can't even temporarly set session keys without getting them committed in a transaction? I think that sessions have to act like a temporary, volatile namespace, something like the REQUEST namespace, but persistent for the time of the session. Chris, in your first response you said that there might be usage patterns where people want sessions to be version-aware (or let's put it more general: transaction-aware). But I think that is not quite true: If I want something like that, I can use plain properties and store them in an object. Finally, let me state what I think is a fact: As of Zope 2.5 b3, you can either use versions OR sessions. If you try to combine them, you'll get into big trouble. This is a major bug, right? Cheers Joachim ----- Original Message ----- From: "Chris McDonough" <chrism@zope.com> To: "Joachim Werner" <joe@iuveno-net.de> Cc: <zope-dev@zope.org> Sent: Monday, January 14, 2002 9:03 PM Subject: Re: [Zope-dev] Re: Temporary Storage + Sessions + Versions: How?

Joachim Werner wrote:

...

Thanks for the hint. I'll try using a versioning storage, though it might be rather inefficient I guess?

Most (all?) versioning storages are also undoing so you'll be keeping undo data that will need to be packed away. It's also hard to manage an undoing mounted storage (no way to pack one from the ZMI). These were the reasons that TemporaryStorage was written in the first place, of course.

...

I think if one is using two Zope features together that are both scheduled to be included for the 2.5 release, there should be no surprises like that one. With Core Session Tracking and Zope 2.4 versioning was fine. And all of a sudden, it didn't work any more. That CAN indeed be disturbing ... :-(

Sorry you had problems. Thanks for bringing it to my attention.

- C

- I have an index_html method that calls an "initializeSession" method at the beginning to initialize certain session variables. (Is there another way to do this?)

Yes, you can use an "script to call when objects are added" method in the transient data container related to the session in order to establish default values.

- As the new sessioning code seems to be working within the transaction machinery, the SESSION.set action causes the mere display of an index_html page (that includes a session initialization method) to be added to the undo logs

The start of a session or changes to the session namespace cause writes to the database in which the data container related to the session is stored. This is the essence of how the sessioning stuff works.

Strictly speaking, this behaviour might be correct, as the SESSION.set indeed changes stuff. But it just isn't usable like that. How am I supposed to use sessions together with versioning at all if I can't even temporarly set session keys without getting them committed in a transaction?

I suspect you're the first person to connect this phenomea with sessions, but it has precedent (see below).

I think that sessions have to act like a temporary, volatile namespace, something like the REQUEST namespace, but persistent for the time of the session.

This is what they are, you've just run in to a limitation of sessions in conjunction with versions. Was your data container stored in the "main" database? It sounds like it was, but you didn't say.

Chris, in your first response you said that there might be usage patterns where people want sessions to be version-aware (or let's put it more general: transaction-aware). But I think that is not quite true: If I want something like that, I can use plain properties and store them in an object.

I dont think I understand. Can you explain more?

Finally, let me state what I think is a fact: As of Zope 2.5 b3, you can either use versions OR sessions. If you try to combine them, you'll get into big trouble. This is a major bug, right?

This depends on your definition of major. FWIW, the same problem happens with methods that Catalog writes in conjunction with versions. You get items "stuck" with a version lock error outside of the version -- objects that you didn't "expect" to be locked. Versions are pretty evil in some ways, this being one. What you're encountering is arguably more a bug in versions that a bug in sessions. Someone operating in a version believes that they are not effecting the site in any way whatsoever, and this is just not true -- what they do impacts the site greatly. Versions are very enticing and mostly a lie. ;-) That said, I agree that versions w/ sessions are a "gotcha" waiting to happen, although I wouldn't agree that it's a bug. Short of rewriting the version code, I think maybe writing a storage that "pretended" to be in a version instead of actually being in one is probably the right answer. This could be a modification to TemporaryStorage or it could be an entirely new storage. However, I think we'd need to consider what the flip side of this carefully. I wouldn't want to err on the side of "magic" in this way without considering the impact. - C

Yeah... Either this or a storage that doesn't cause a version lock error when accessing an object that has been changed in a version are potential solutions. ----- Original Message ----- From: "Joseph Wayne Norton" <norton@alum.mit.edu> To: "Chris McDonough" <chrism@zope.com> Cc: "Joachim Werner" <joe@iuveno-net.de>; <zope-dev@zope.org> Sent: Monday, January 14, 2002 11:53 PM Subject: Re: [Zope-dev] Re: Temporary Storage + Sessions + Versions: How?

Chris and Joachim -

Maybe this is too simplistic of an approach ... but why not have the session data manager automatically create a new, session data container (temporary storage) for a given zope version. The session data manager can be optimized for the case of no version and then when and if needed create temporary storages on demand for a particular version.

- j