SESSION updates don't always take
Hello all, We have run into intermittent problems where the updates to items in the SESSION object are not always saved. I've boiled the problem down to the following set of steps. 1. The SESION object stores a list of items, in the test case, it is a list with a single number. 2. We use a function to mutate that list directly by passing in a reference to the list, ie function(SESSION['listName']) 3. The function makes changes to the list directly. It seems that when a single user is using the system, this works consistently about 99% of the time. But, for some reason, when a second test case running on a different machine/browser starts up, almost always we get an immediate inconsistency between what should be in the session and what is actually there in the first test case. Now, it will happen running a solo version of the test case as well, just far more rarely. Note that running two test cases inside of tabs in firefox will immediately become inconsistent because they share the same session object within zope. But running two browsers (ie & firefox) or just using 2 different machines as the clients will trigger the problem. I also found that if I make any other unrelated change to the session object using SESSION.set() it appears to fix the problem. My hunch is that by manipulating the list directly without using session.set, we are causing a situation where sometimes the SESSION variable doesn't get marked as dirty and saved. Are there any other ideas out there why we would be seeing the behavior we are seeing? Thanks, -Chris Zope 2.7.3 on python 2.3.4 Linux kernel 2.6.8 ************************************************************************** WARNING, this test case may stress the server it runs against due to auto-reloading once per second. ************************************************************************** 1. Create DTML document by copying in the contents attached. 2. Create a python script with the contents attached. 3. View the page in two completely different browsers (to trigger separate zope sessions) 4. The pages will run automatically reloading once a second and checking what is in the session to what it thinks should be in the session. I get an inconsistency within 50 runs on at least one of the browsers. Often within 10 runs one of them finds an inconsistency. -------------- testSessionBug (DTML Doc) -------------- <!-- initialize first time in --> <dtml-if numTests><dtml-else> <dtml-call "REQUEST.set('numTests', 0)"> <dtml-call "SESSION.set('numTests', [0])"> </dtml-if> <html><head> </head><body> <h2><dtml-var title_or_id></h2> <p> <dtml-if "SESSION.has_key('numTests') and numTests<>0 and int(SESSION['numTests'][0])<>int(numTests)"> <b>Found Session List inconsistency</b> <br> SESSION=<dtml-var "SESSION['numTests'][0]"><br> Should be=<dtml-var numTests> <dtml-else> <dtml-var numTests> complete without error. <!-- Increment counter --> <dtml-call "REQUEST.set('numTests', int(numTests)+1)"> <!-- Write to SESSION --> <dtml-call "writeToSession(REQUEST.SESSION['numTests'], numTests)"> <!-- Update other variable, enable to keep from having a inconsistencies. --> <d-call "SESSION.set('test',1)"> <!-- Javascript to reload page --> <script Language="javascript"> setTimeout('self.location="testSessionBug?numTests=<dtml-var numTests>"', 1000); </script> </dtml-if> <br><br> <a href="testSessionBug">Start Over</a> </p> </body></html> -------------- writeToSession (python script) -------------- ## Script (Python) "writeToSession" ##bind container=container ##bind context=context ##bind namespace= ##bind script=script ##bind subpath=traverse_subpath ##parameters=valList, val ##title= ## valList[0]=val -- Chris Kratz
Your hunch is entirely correct. This behavior is actually documented within http://www.plope.com/Books/2_7Edition/Sessions.stx in the section entitled "mutable data stored within session objects". This isn't really a general sessioning issue, it's more of a ZODB issue (which sessions use "under the hood"). On Wed, 2005-03-09 at 15:40, Chris Kratz wrote:
Hello all,
We have run into intermittent problems where the updates to items in the SESSION object are not always saved.
I've boiled the problem down to the following set of steps.
1. The SESION object stores a list of items, in the test case, it is a list with a single number. 2. We use a function to mutate that list directly by passing in a reference to the list, ie function(SESSION['listName']) 3. The function makes changes to the list directly.
It seems that when a single user is using the system, this works consistently about 99% of the time. But, for some reason, when a second test case running on a different machine/browser starts up, almost always we get an immediate inconsistency between what should be in the session and what is actually there in the first test case. Now, it will happen running a solo version of the test case as well, just far more rarely. Note that running two test cases inside of tabs in firefox will immediately become inconsistent because they share the same session object within zope. But running two browsers (ie & firefox) or just using 2 different machines as the clients will trigger the problem.
I also found that if I make any other unrelated change to the session object using SESSION.set() it appears to fix the problem.
My hunch is that by manipulating the list directly without using session.set, we are causing a situation where sometimes the SESSION variable doesn't get marked as dirty and saved. Are there any other ideas out there why we would be seeing the behavior we are seeing?
Thanks,
-Chris
Zope 2.7.3 on python 2.3.4 Linux kernel 2.6.8
************************************************************************** WARNING, this test case may stress the server it runs against due to auto-reloading once per second. **************************************************************************
1. Create DTML document by copying in the contents attached. 2. Create a python script with the contents attached. 3. View the page in two completely different browsers (to trigger separate zope sessions) 4. The pages will run automatically reloading once a second and checking what is in the session to what it thinks should be in the session.
I get an inconsistency within 50 runs on at least one of the browsers. Often within 10 runs one of them finds an inconsistency.
-------------- testSessionBug (DTML Doc) -------------- <!-- initialize first time in --> <dtml-if numTests><dtml-else> <dtml-call "REQUEST.set('numTests', 0)"> <dtml-call "SESSION.set('numTests', [0])"> </dtml-if>
<html><head> </head><body> <h2><dtml-var title_or_id></h2> <p>
<dtml-if "SESSION.has_key('numTests') and numTests<>0 and int(SESSION['numTests'][0])<>int(numTests)"> <b>Found Session List inconsistency</b> <br>
SESSION=<dtml-var "SESSION['numTests'][0]"><br> Should be=<dtml-var numTests>
<dtml-else> <dtml-var numTests> complete without error. <!-- Increment counter --> <dtml-call "REQUEST.set('numTests', int(numTests)+1)">
<!-- Write to SESSION --> <dtml-call "writeToSession(REQUEST.SESSION['numTests'], numTests)">
<!-- Update other variable, enable to keep from having a inconsistencies. --> <d-call "SESSION.set('test',1)">
<!-- Javascript to reload page --> <script Language="javascript"> setTimeout('self.location="testSessionBug?numTests=<dtml-var numTests>"', 1000); </script> </dtml-if>
<br><br> <a href="testSessionBug">Start Over</a>
</p> </body></html>
-------------- writeToSession (python script) -------------- ## Script (Python) "writeToSession" ##bind container=container ##bind context=context ##bind namespace= ##bind script=script ##bind subpath=traverse_subpath ##parameters=valList, val ##title= ## valList[0]=val
On Wednesday 09 March 2005 03:42 pm, Chris McDonough wrote:
Your hunch is entirely correct. This behavior is actually documented within http://www.plope.com/Books/2_7Edition/Sessions.stx in the section entitled "mutable data stored within session objects". This isn't really a general sessioning issue, it's more of a ZODB issue (which sessions use "under the hood").
Thanks for the response Chris. It's nice to know that it's not a bug, or at least it is a documented bug. It's just unfortunate that it works most of the time such as during development. I don't like gremlins. Ah well, perhaps others in the list can learn from my experience. In short to close the thread, any mutation to an item in a SESSION object must be stored with a call to set. Otherwise the code will fail intermittently. -- Chris Kratz
On Wed, 2005-03-09 at 16:59, Chris Kratz wrote:
On Wednesday 09 March 2005 03:42 pm, Chris McDonough wrote:
Your hunch is entirely correct. This behavior is actually documented within http://www.plope.com/Books/2_7Edition/Sessions.stx in the section entitled "mutable data stored within session objects". This isn't really a general sessioning issue, it's more of a ZODB issue (which sessions use "under the hood").
Thanks for the response Chris. It's nice to know that it's not a bug, or at least it is a documented bug. It's just unfortunate that it works most of the time such as during development. I don't like gremlins. Ah well, perhaps others in the list can learn from my experience.
Yup, this is a common issue that bites many people when they do ZODB programming. For better or worse, we've made the scripter into a ZODB programmer via offering sessions.
On Wednesday 09 March 2005 05:09 pm, Chris McDonough wrote:
On Wed, 2005-03-09 at 16:59, Chris Kratz wrote:
On Wednesday 09 March 2005 03:42 pm, Chris McDonough wrote:
Your hunch is entirely correct. This behavior is actually documented within http://www.plope.com/Books/2_7Edition/Sessions.stx in the section entitled "mutable data stored within session objects". This isn't really a general sessioning issue, it's more of a ZODB issue (which sessions use "under the hood").
Thanks for the response Chris. It's nice to know that it's not a bug, or at least it is a documented bug. It's just unfortunate that it works most of the time such as during development. I don't like gremlins. Ah well, perhaps others in the list can learn from my experience.
Yup, this is a common issue that bites many people when they do ZODB programming. For better or worse, we've made the scripter into a ZODB programmer via offering sessions.
The sad thing is that I knew this to be the case with standard ZODB programming. Hence the huch. What I didn't realize is that the SESSION code worked the same way for some reason. Oh well, thanks again. -- Chris Kratz
On Wed, 09 Mar 2005 17:12:43 -0500, Chris Kratz wrote:
On Wednesday 09 March 2005 05:09 pm, Chris McDonough wrote:
Yup, this is a common issue that bites many people when they do ZODB programming. For better or worse, we've made the scripter into a ZODB programmer via offering sessions.
The sad thing is that I knew this to be the case with standard ZODB programming. Hence the huch. What I didn't realize is that the SESSION code worked the same way for some reason.
Oh well, thanks again.
While we're on the topic of the one downside of making Session objects ZODB objects like any other, I thought I'd jump in and point out the advantage. I've worked with other systems where sessions are just a standard in-memory object, and this is a much nicer approach. Since sessions are ZODB objects, you can switch to store your sessions in a database, or in memory on a ZEO server, just by playing with your configuration. All the usual ZODB mechanisms for transaction handling and changed-object invalidation come into play for free, giving you a distributed and/or fully persistent session store which is much easier to use and set up than most, and with far fewer limitations on the structure of your session data. Thanks, Malcolm. -- [] j a m k i t web solutions for charities malcolm cleaton T: 020 7549 0520 F: 020 7490 1152 M: 07986 563852 W: www.jamkit.com
participants (3)
-
Chris Kratz -
Chris McDonough -
Malcolm Cleaton