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

[Martijn Pieters]

At 13:16 18/10/99 , Johan Carlsson wrote:
> > Every change to a ZODB persistent object causes another transaction to be
> > written to storage. A busy site with lots of sessions will cause the
> > Data.fs file to grow at quite a rate. Pavlos choose this solution
> > to avoid
> > this growth.
> >
> > 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.
>
>Ok.
>One (or more:) question(s).
>
>- When does filestorage or rdbm-storage write to disk?

I don't really know, and don't have the time right now to figure this out 
properly. Jim Fulton will be a better person to answer this. Also, you 
could look through the ZODB UML Model:

   http://www.zope.org/Documentation/Developer/Models/ZODB


>- 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).

_v_ properties are not shared between threads. My understanding is that 
every thread will get its own copy of the object from the ZODB, which 
propagates changes to those objects to other threads. As _v_ properties are 
not stored, no other thread will ever see them, defeating their use as 
session variables. They are only useful for caching.

There is at the moment no API for using the ZODB memory cache outside the 
ZODB code itself, afaik.

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

Not so much slow down as cause undesirable side effects, like storing a 
complete change history of the changed object. See the ZODB UML for more 
information.


>Transaction support for sessions are one of the things you
>really want.

Oh yes, definitely. With the current implementation of the ZODB however, 
any session specific data that has a reasonably high change rate will have 
to be stored outside the ZODB. The ZODB was designed with long-term 
persistence in mind, not short term.

There are plans to allow use of multiple Storage types within one Zope 
object hierarchy. Also, there are Storage available now, that do not 
support Undo (discard old versions). When multiple storages are supported, 
you could use a in-memory storage without undo for session data.

>  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.

I am not sure wether or not this will work. I think that a Version only 
supports a long-term transaction on ZODB stored data, not on any external 
data. But I may be mistaken.

--
Martijn Pieters, Web Developer
| Antraciet http://www.antraciet.nl
| Tel: +31-35-7502100 Fax: +31-35-7502111
| mailto:mj@antraciet.nl http://www.antraciet.nl/~mj
| PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149
------------------------------------------