No, it still saves the sessions to disk even if you use Memory. You might
want to use Memory because it is the most efficient of the session stores
(assuming sufficient amounts of memory are available), but still retain the
ability to restart the appserver and preserve sessions. The naming is
counterintuitive, I'll admit.
We talked about adding an extra option to never store sessions to disk, but
I believe we never did. Patches welcome...
Another approach would be to add yet another session store "MemoryOnly" or
something like that.
> -----Original Message-----
> From: Stuart Donaldson [mailto:stuartd@...]
> Sent: Tuesday, January 28, 2003 10:30 AM
> To: 'Michael Engelhart'; webware-discuss@...
> Subject: RE: [Webware-discuss] how do i prevent a KeyError on
> session id
> w hen i restart?
> Not having tried it myself, but I thought you could do this
> by setting the
> Application.configs setting of 'SessionStore' to 'Memory'
> rather than the
> default of 'Dynamic'.
> > -----Original Message-----
> > From: Michael Engelhart [mailto:mengelhart@...]
> > Sent: Tuesday, January 28, 2003 7:17 AM
> > To: webware-discuss@...
> > Subject: Re: [Webware-discuss] how do i prevent a KeyError on
> > session id
> > w hen i restart?
> > I still think this should be addressed by putting the
> ability to NOT
> > store sessions to disk at all in the configuration parameters.
> > My workaround in 0.7 is to comment out the code that stores Memory
> > sessions to disk (which in my mind it should anyway).
> Memory to me
> > implies transient, not persistent. I also believe that storing
> > sessions to disk is a security hole as well in mnay cases but
> > that may
> > just be me. It would be as easy as changing the Session code to
> > having Memory Sessions never persist between application restarts.
> > That way they would just go away after they timed out.
> > Mike Engelhart
> > On Tuesday, January 28, 2003, at 09:57 AM, Stuart Donaldson wrote:
> > > Which version of Webware are you using?
> > >
> > >> From the looks of the trace back you provided, it appears
> > the problem
> > >> is
> > > that the decoding of the serialized session on the disk
> is failing,
> > > rather
> > > than the session is missing.
> > >
> > > This can be caused by having non-serializable objects in
> > the Session
> > > object.
> > > Until recently, the problem would show up just like this,
> > because the
> > > pickled session object was corrupted since the entire
> > object could not
> > > be
> > > stored.
> > >
> > > The current behavior (as of 0.8b1) is to display an error
> > when trying
> > > to
> > > pickle the session out to disk, and to not store a
> > corrupted session on
> > > disk. The error goes through the
> > Application.handleException() method
> > > which
> > > by default will print the message to stdout.
> > >
> > > Note you won't see the pickling exception in your browser because
> > > there is
> > > no session associated with the error.
> > >
> > > If you are using 0.8b1, please let me know, as there must
> > be some other
> > > problem.
> > >
> > > But generally I suspect your problem is that you have
> > something in the
> > > session object which can't be pickled like an open file
> or database
> > > connection.
> > >
> > > -Stuart-
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Webware-discuss mailing list
> > Webware-discuss@...
> > https://lists.sourceforge.net/lists/listinfo/webware-discuss
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> Webware-discuss mailing list