[Zope] Question on: How-To: When Cookies won't do it
Johan Carlsson
johanc@torped.se
Mon, 18 Oct 1999 13:16:26 +0200
> > I browsed trough the How-To: When Cookies won't do it
> > and I have some questions.
> >
> > How much speed do you really gain from using file for
> > data marshaling?
> >
> > Would it be a good idea to use Object Pooling (pre created
> > objects) to speed up a session object solution?
> >
> > The reason I don't like the file based solution is that
> > I won't scale with ZEO but a Object solution would, right?
> > There would also be possible for cool stuff like session
> > failover and long time session (much list version but individual
> > and perhaps with a limited scoop)
> >
> > Another reason is that I like the concept of the ZODB,
> > why think in a non ZODB way?
>
> One word: Transactions.
>
> 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?
- 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).
- How does transactions slow down the process, and how are
transactions connected to storage (in this situation)?
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.
Regards,
//johan