Below is a very simple servlet and class that demonstrates what
happens. I tried switching the SessionStore to 'Memory', but it
doesn't seem to like trying to reload the file from the Sessions/
<id>.ses file:
Error loading session from disk: 20050617152441-
f98fac1ef9b9bb3f564e3c53e5e69b96
[Fri Jun 17 15:25:04 2005] [error] WebKit: Error while executing
script None
Traceback (most recent call last):
File "WebKit/SessionFileStore.py", line 53, in __getitem__
To see how the servlet below re-loads the pickled data twice, just
put this into a context directory and go to http://localhost/
<adapter>/SessionTest -- reload a few times, then kill your appserver
(to see it write out the pickled session file), and then start the
appserver and visit that page again -- you'll see the print statement
called twice.
Also, below the test servlet, I included a diff of
SessionFileStore.py where I commented out the lines that does the
secondary __getitem__ of the session identifier. I'm not sure what
implications that might have though...
Thanks for the feedback,
Tracy
# --- BEGIN SessionTest.py
from time import time
from WebKit.Page import Page
class SessionTest(Page):
def awake(self, trans):
Page.awake(self, trans)
req = self.request()
ses = self.session()
history = ses.value('history', None)
if history is None:
history = History()
history.addVisit(req)
ses.setValue('history', history)
def writeBody(self):
ses = self.session()
self.write('<ul>')
for ts, req in ses.value('history').requests:
self.write('<li>%s (%s)</li>' % (ts, req))
self.write('</ul>')
class History(object):
def __init__(self):
self.visits = 0
self.requests = []
def addVisit(self, request):
self.visits += 1
self.requests.insert(0, (time(), request.uri()))
def __getstate__(self):
print "Getting state -> %s" % vars(self)
return (self.visits, self.requests)
def __setstate__(self, (visits, requests)):
print "Setting state -> %s" % repr((visits, requests))
self.visits = visits
self.requests = requests
# --- END SessionTest.py
# --- BEGIN svn diff SessionFileStore.py
Index: SessionFileStore.py
===================================================================
--- SessionFileStore.py (revision 2330)
+++ SessionFileStore.py (working copy)
@@ -94,9 +94,9 @@
filename = self.filenameForKey(key)
if not os.path.exists(filename):
raise KeyError, key
- sess = self[key]
- if not sess.isExpired():
- sess.expiring()
+# sess = self[key]
+# if not sess.isExpired():
+# sess.expiring()
os.remove(filename)
def has_key(self, key):
# --- END svn diff SessionFileStory.py
On Jun 17, 2005, at 9:58 AM, Geoffrey Talvola wrote:
This clearly sounds like a bug. Perhaps as a workaround you could
switch to
SessionMemoryStore and see if it avoids the problem. It should
only pickle
when stopping the appserver and should only unpickle when starting
it. I'm
curious if it also ends up loading the pickled file twice.
- Geoff
Tracy S. Ruggles wrote:
I've got an object that I'm putting to a session object that has its
own __getstate__ and __setstate__ method defined. After a restart of
webkit, the SessionDynamicStore object loads the pickled file twice,
calling my object's __setstate__ method twice.
Specifically, beginning at line 130 of SessionDynamicStore in
"MoveToMemory", the code first gets the object via the __getitem__
method (decoding via a pickle.load) and then deletes it from itself
via its own __delitem__ method -- which in turn calls __getitem__
again so it can call its .expiring method before doing an os.remove
on the actual file.
Has anyone had trouble with having an expensive __setstate__ method
for objects being put into memory? My object's __setstate__ method
essentially bootstraps itself into existence with a minimal amount of
info pickled from the __getstate__ method since the data inside my
object is not pickle-able.
Is there a way around having a pickled object being created twice by
the SessionStore? I'm looking at creating a class attribute in my
object that would keep track of whether these objects have been
bootstrapped or not.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Webware-discuss mailing list
Webware-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/webware-discuss
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Webware-discuss mailing list
Webware-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/webware-discuss
