[Zope] ZEO and Sessions.

[Chris McDonough]

On Tue, 2005-04-12 at 20:01, Richard Jones wrote:
> On Wed, 13 Apr 2005 09:44 am, you wrote:
> > On Tue, 2005-04-12 at 19:08, Richard Jones wrote:
> > > Is there a viable non-versioned alternative to the filestorage approach?
> > > My sessions database grows ridiculously quickly. I'm also fairly sure
> > > it's causing problems when my site gets ~5 requests a second (yes, that
> > > low)
> >
> > You could use temporarystorage on the ZEO server if you don't really
> > need your session data to be persistent across ZEO server restarts.
> > This is what Fernando appeared to do in the end.
> 
> Having sessions persist across ZEO restarts is a handy thing.

Yup.  I've not really needed it so far, but if you need it, you need
it...

> Also, I never figured how to configure a temp storage in a ZEO server. I 
> started looking once, but either ran into a dead end or got distracted (or 
> both ;)

Probably something like what Fernando had on the client:

<zodb_db temporary>
  mount-point /foo/bar
  # ZODB cache, in number of objects
  cache-size 5000
  <zeoclient>
    server localhost:8999
    storage temp
    name zeotemporary
    var $INSTANCE/var
    # ZEO client cache, in bytes
    cache-size 20MB
    # Uncomment to have a persistent disk cache
    #client zeo1
  </zeoclient>
</zodb_db>

And in the ZEO server's zeo.conf file:

%import tempstorage
<temporarystorage temp>
   name sessions
</temporarystorage>

This resource is useful too:

http://longsleep.org/howto/sharesessionwithzeo

> > There are no well-maintained nonundoing storages that I know of other
> > than temporarystorage.  Once upon a time, BerkeleyStorage minimal used
> > to work, but its gone the way of the dinosaurs apparently.
> 
> And I distrust anything related to Berkely DB :)

I hear ya! ;-)

> > I think any sessioning setup that uses a ZEO-backed storage will be more
> > conflict-prone than one that doesn't use ZEO, just because the
> > transaction commit time is typically longer.  I'm not sure if this is
> > the problem you mention.
> 
> Could be.

It'd be pretty obvious with an inordinate number of conflict errors in
the event log.  "inordinate" is relative, though, so I'm not sure what
to name as a number per minute for your app.  You can get a sense of
what's normal under contrived load by reading:

http://www.plope.com/Members/dunny/conflicts/view

> > Probably not hard.  You could write a "session data manager"
> > implementation that used a relational database.  The interface for those
> > things is in Products/Sessions/SessionInterfaces.py
> 
> Yeah, I remember poking around that code way back, and it seemed reasonable. 
> Its interactions with transactions are the bits that scare me. Using a 
> standard RDBMS connection would probably solve that though.

Yeah.  Probably OK to use a ZRDB connection, those are controlled
automatically.

- C