[Zope-dev] CoreSessionTracking 0.8 strangeness

[Chris McDonough]

This is very odd, as cst depends on ZODB locking just like everything
else in Zope, and uses the same transaction facilities and semantics.

Now this may *be* the problem... some other folks have explained a
problem where newly-created session data "disappears" if the
long-running request that created it is aborted... this may make sense,
because the request never gets the chance to finish, and the session
data object never gets committed to the database because the ZODB
transaction is aborted.

It may be the case (especially if you're using frames or  multiple
windows) that simultaneous concurrent initial requests for a session
data object from the same client might cause one of two newly-created
data objects to be lost.

But I can't imagine a case where a session data object exists for a
while (a few minutes), and then a client comes in with the same
sessionid, and a new session data object is created for him, not
*replacing* the old one, but in addition to the old one... the only
possibility for something like this that I can see is on initial
request, or if a particularly long-running method creates a session data
object, and a user comes in directly after it... ah, wait.  I think I
see how this can happen.

1.  User hits /longrunningmethod.

2.  /longrunningmethod creates a session data object as part of its
    operation.

3.  /longrunning method requires 1 minute to process completely.

4.  In the meantime, the user (in a separate window or frame) visits
    /shortrunningmethod.

5.  /shortrunningmethod creates a session data object as part of its
operation.

6.  /shortrunningmethod completes and the session data object it created
    is committed to the ZODB.

7.  User visits /shortrunningmethod2, which modifies the existing
    session data object, /shortunningmethod3, which also does this,
    etc.

8.  In the meantime, /longrunningmethod finishes and replaces the
session data
    object which has stuff in it from the shortrunningmethods with the
one
    it created.

I'm not completely 100% sure about this, but at least it's something to
test.  Could this be what's happening to you?

I may have been overzealous when dealing with confict error problems
here... basically, the conflict error detection stuff is disabled for
session data objects, which makes this sort of thing possible and
likely.  Conflict error detection is the ZODB equivalent of
record-locking... and when it's ignored, you can have some of the same
problems that happen in a nontransactional system (like the problem I
outlined above).  Sigh.

- C


Bjorn Stabell wrote:
> 
> Hi,
> 
> We're developing a shopping cart using the CoreSessionTracking product
> v0.8, but we've run into a strange problem; once in a while
> getSessionData() will create a  new session data object (the token value
> remains the same), and us that for a while.  Now we'll end up having two
> different shopping cart objects, with getSessionData() randomly
> returning one of them them.  We're running Zope 2.3.1.  Could it be that
> some threads can't find the shared session data object and creates their
> own?  The only thing changing between each HTTP request is the thread
> serving the request, AFAIK.
> 
> Regards,
> --
> Bjorn Stabell <bjorn@exoweb.net>
> 
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope )