[Zope-dev] CoreSessionTracking 0.8 strangeness

[Bjorn Stabell]

Chris,

It is definately not what you expect, although it was a good guess :)
Here's an example of what happens:

  1. User adds Burger to shopping cart
    -> Shopping cart shows Burger
  2. User adds Coke to shopping cart
    -> Shopping carts shows Burger and Coke
  3. User adds Fries to shopping cart
    -> Shoppping cart is empty(!)
  4. User adds Fries to shopping cart
    -> Shopping cart only shows Fries
  4. User adds Apple Pie to shopping cart
    -> Shopping cart shows Fries and Apple Pie
  5. User adds Ice Cream to shopping cart
    -> Shopping cart shows Burger, Coke, and Ice Cream(!)
  ...and so on...

Sometimes, clicking links that don't even touch the shopping cart will
make it disappear, e.g., viewing a new product category in the catalog.
It seems pretty random, and it is hard to reproduce reliably.  The
shopping cart is displayed on the same page as the catalog.  Any ideas?

PS! I have noticed that in other cases Zope is a acting a little bit
random too, e.g., when it comes to which character set is used;  it will
not obey our commands to set it to gb2312 about 1 out of 10 times.  That
could be an IE bug, but I doubt it.

Bye,
--=20
Bjorn

-----Original Message-----
From: Chris McDonough [mailto:chrism@digicool.com]
Sent: Friday, May 11, 2001 20:47
To: Bjorn Stabell
Cc: zope-dev@zope.org; Exoweb
Subject: Re: [Zope-dev] CoreSessionTracking 0.8 strangeness


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:
>=20
> Hi,
>=20
> 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.
>=20
> Regards,
> --
> Bjorn Stabell <bjorn@exoweb.net>
>=20
> _______________________________________________
> 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 )