[Zope] Question on: How-To: When Cookies won't do it

[Pavlos Christoforou]

Hi Johan -

> > 
> > I suggested trying to use a seperate instance of the ZODB, using 
> > MemoryStorage, so that all session objects would be in memory. This could 
> > then maybe be extended to support ZEO as well, but I haven't really dived 
> > into that yet.

Martijn's suggestion is probably the best (as usual), but it
involves more effort (and thinking!) than the 10 lines script I wrote.


> Ok.
> One (or more:) question(s).
> 

> - Why can't the session object rely on the ZODB memory cache.
>   They are (for the most) fast deployed objects. 
>   Maybe even use _v_ objects (which would be automatically destroyed).

That is one way but your temporary data will be lost as soon as the object
is deactivated (as you mentioned). With tmpStorage I can retrieve the info
at any point, even days later.

> 
> - How does transactions slow down the process, and how are
>   transactions connected to storage (in this situation)?

I am not sure what is the overhead of transactions but what I am trying to
avoid is not transaction control (in principle I could make tmpStorage
transaction aware), but as Martijn mentioned, to avoid new object
creation.
> 
> 
> Transaction support for sessions are one of the things you
> really want. I even been thinking about using private versions
> for sessions, for instance in a e-shop you would be able to 
> customize your order directly in the OLAP-system but within a
> version. Not until you commit your transaction the changes 
> gets propagated to the OLAP-system.

Agreed -

Again, tmpStorage is a simple solution that is thread safe and fast. Those
were my requirements at the time. A proper more general solution is
the one mentioned by Martijn.


Pavlos