RE: [Zope-dev] CoreSessionTracking 0.8 strangeness
Yes, it is entirely with cookies, and we are using frames, although the there's only one sub-frame accessing the session object (that's where we show the shopping cart). -Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 12, 2001 23:18 To: Bjorn Stabell Cc: [EMAIL PROTECTED]; Exoweb Subject: Re: [Zope-dev] CoreSessionTracking 0.8 strangeness Bjorn, Is this entirely with cookies? Or are you using url-encoding anywhere? Does your application make use of frames or multiple windows? - C Bjorn Stabell wrote: 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, -- Bjorn ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
RE: [Zope-dev] CoreSessionTracking 0.8 strangeness
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, -- Bjorn -Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 20:47 To: Bjorn Stabell Cc: [EMAIL PROTECTED]; 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: 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 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 ) ___ Zope-Dev maillist
Re: [Zope-dev] CoreSessionTracking 0.8 strangeness
Bjorn, Is this entirely with cookies? Or are you using url-encoding anywhere? Does your application make use of frames or multiple windows? - C Bjorn Stabell wrote: 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, -- Bjorn ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] CoreSessionTracking 0.8 strangeness
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 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
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: 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 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 ) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
