Re: [Webware-devel] Patch that handles sessions which can not be encoded for saving to disk.

[Ian B. <ia...@co...>]

On Wed, 2003-01-08 at 19:30, Stuart Donaldson wrote:
> Regarding patch  630505
>   
> http://sourceforge.net/tracker/index.php?func=detail&aid=630505&group_id=4866&atid=304866
> 
> This catches the case where an error occurs during encoding while saving 
> the session to a file.  The patch to SessionFileStore.py safely handles 
> the exception and does not save a corrupted file (Current behavior is to 
> store a session which can't be loaded.)
> 
> The patch to SessionDynamicStore however only removes the session from 
> memory if it was successfully saved to disk.
> 
> This may be reasonable for debugging, but is it reasonable for a 
> released version?  In a released system, won't this open the door for 
> extra large memory consumption?  Couldn't it also interfere with the 
> session caching?  

I started looking at it, and I also thought that it was both the Right
Thing and the Incomplete Thing.  Certainly the code to remove corrupt
session files is good.  But I'm not sure what to do after that.  Should
the session be killed entirely, to be started anew?  Should the corrupt
session file be deleted, the session left in memory, and an exception
raised?  Or an exception without leaving the session in memory?  Or no
exception and it stays in memory?

In my own development I'd like to have an exception raised, absolutely. 
I don't want my application to be quietly broken, with the only evidence
being that sessions aren't saved during restarts.  But then, I don't
know if I'd want the session destroyed in production use if not
necessary -- the error really *is* recoverable in most cases.  In that
situation I'd like to keep the session, and have an error logged, and no
exception raised.  A setting?  I don't like settings, but both seem
reasonable.  We could fit it in with the non-Pickling sessions 

> It seems that in released version of the product, that the safest 
> failure would be to just discard the session if this occurred. 
>  Information about the failure is still printed to stdout to help in 
> tracking things down.  It seems like this might also be an argument for 
> a generic logging interface, to send something to a permanent log as well.

Well, we have a generic logging interface (the logging module). 
Probably all we have to do is come up with a convention about how we'll
use it.

  Ian