To me, it seems like the safest behavior for the Dynamic store on a pickling
error is to not remove the session from memory, AND to email an error
message to the administrator if emailing of errors is configured.
> -----Original Message-----
> From: Stuart Donaldson [mailto:stu@...]
> Sent: Wednesday, January 08, 2003 8:31 PM
> To: Webware devel
> Subject: [Webware-devel] Patch that handles sessions which can not be
> encoded for saving to disk.
> Regarding patch 630505
> 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?
> 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.
> Your thoughts?
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> Webware-devel mailing list
From: Stuart Donaldson <stuartd@al...> - 2003-01-09 20:48:41
I lean towards the net effect that Geof proposed of not saving the file,
removing the session from memory, and logging the exception so that the
admin can follow up. Does this meet our needs adequately?
Could we solve this by using the app._exceptionHandlerClass(app, None,
excInfo)? The transaction would be passed as None, because there is no
current transaction while saving a session to disk. The ExceptionHandler
class looks like it is already designed to handle a non-transaction oriented
exception. This would log the exception normally, and e-mail if configured
to do so.
I would probably implement a suitable accessor function, perhaps
Application.handleException(excInfo) which would be similar to
handleExceptionInTransaction() but of course use None for a transaction.
Although we could possibly get away with calling
handleExceptionInTransaction() with transaction=None.
Was this what you meant by the logging module? Or were you referring to the
new logging module coming in python 2.3?