Re: [Webware-discuss] Session storage

[Jay L. <js...@mi...>]

I'd like to propose a further addition to all this.  Assuming that the
group feels my argument below has some merit.

Chuck has added a SessionStore super class and MEmory and File
subclasses which are very nice.  In fact I was coming to add something
similar myself when I realized he had done it.  But I was thinking of
one additional thing.

Currently, we've got a hack in there that causes the code that calls
session.sleep() to re-add the session in the session dictionary to force
the FileStorage to save it to disk.  (Confusing, I know, see the code in
CVS, line 400 in Application.py)

INstead, let's add a call at the end of dispatchRequest, which calls a
function in the sessionStorage object named, maybe,
storeIndividualSession.  At that point, the session is stored and all
the file stuff happens.

This way, we could have that storeIndividualSession function  be a
"pass" in the Memory store, and add another function to
SessionMemoryStore called storeAllSessions, which would be called from
the session sweeper thread and would pickle the whole sessions
dictionary, like I've described below.  This function would be a pass
for the FileStorage version.


This all leaves it open for other storage mechanisms, like db backed,
that'll be necessary down the road.

Jay


Jay Love wrote:
> 
> Chuck Esterbrook wrote:
> >
> > At 08:24 PM 8/11/00 -0400, Jay Love wrote:
> > >All I'm saying is the file locking will be ugly and slow for every
> > >session access, which is what you're proposing.  Take it one thought
> >
> > I don't see what's ugly and yes there is a performance hit which we'll have
> > to assess.
> 
> OK, I think your thought was to have a directory where each session is
> pickled into it's own file.  My thinking was pickle the whole sessions
> dictionary periodically into one big file.  A little confusion on what
> we're referring to.
> 
> So you're saying add a function at the end of maybe dispatchRequest
> that takes that session and saves it to a file immediately.  THen when a
> request comes in, we get the stored session id from the cookie, search
> the directory where sessions are stored and see if it's there, and if so
> unpickle.  Right?  Would you continue to hold the Session in memory as
> well?
> 
> If the Session doesn't stay in memory, I can see a problem with this for
> my needs.  What if I had a db session in a Can in the Session or
> directly in the Session object?  And what about DB transactions that
> span multiple requests.  You know, a shopping cart situation, where you
> start a db transaction with their first request where they add an item
> to the cart, and then subsequest requests add more items, then they
> checkout.  You might want to have that whole sequence of actions be
> encapsulated in one DB transaction.
> 
> >
> > >further.  For the AppServers, better to do it periodically in the
> > >session sweeper thread. No file locks to deal with, and a lower
> > >performance hit.
> >
> > What does that mean "do it periodically in the session sweeper thread"?
> > What's "it"?
> 
> I was thinking of just dumping the whole app-wide sessions dictionary to
> a file after each sweep of the session cleanup code.  This is geared
> toward fault tolerance and the need to restart the Appserver.  Maybe add
> a function that also does it on a normal shutdown.
> 
> Jay