Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
dtml-let data=SESSION.getSessionData()
manage=REQUEST.get('manage_content') or
data.get('manage_content')
dtml-unless manage
dtml-call data.set('manage_content','NO')
/dtml-unless
dtml-in data.keys()
dtml-let si=sequence-item
dtml-call REQUEST.set(si, data[si])
/dtml-let
/dtml-in
/dtml-let
This will work for the manage_content, but I want to make the whole
request persistent. E.g., box states, search filters, and sequence-start
variables for batching are all made persistent ...
I'm also confused why you're using YES and NO to represent a boolean
instead of just checking that a key exists or is true.
Just consider it a bad habit ;-) -- I had some trouble working with booleans
some time ago, so I switched to this more explicit version.
___
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: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
To further try to track this problem down, I've developed a burger, fries, coke application in honor of this thread. So far, I've eaten 84 burgers, 31 cokes, and 42 fries. I can't seem to break this thing, and I'm not hungry anymore. :-( I just wanted to throw this out there. I'm certain this isn't the problem because it's too simple, but just in case... How many session data managers do you (Howard, Michael, Joachim, and.. I forget who else is having problems) have? Just one, I assume. It's not possible that different DTML pages in your application call out to *different* session data managers, is it? Maybe via unanticipated acquisition? I know the answer is probably no, but I need to ask, because the symptoms are consistent with this kind of misconfiguration. Questions (assuming the previous question was a throwaway): Is there something in the standard_html_header that sets request variables out of session data? Or is this done via an access rule? Or is the session data logic just embedded within every page? Is everybody using cookies? Is everybody using the RAM-based session data container? How long is the data container timeout? Is this too many questions already? ;-) stuffed-ly y'rs, - C Chris McDonough wrote: Chris McDonough wrote: I just wrote a test case that emulates many visitors firing off sessions and making changes to shared data objects simultaneously. It even emulates aborted connections. Unfortunately, I see nothing out of the ordinary. :-( This is very frustrating. Maybe the problem folks are experiencing with CST are related to the None has no attribute 'load' bug that pops up every so often using a mounted storage (RAM-based session data containers use a mounted storage internally). If there's any chance that you can turn the STUPID_LOG_FILE on, if the problem happens while you're using the site, it would be helpful to be able to correlate (or not correlate) the problems folks are having with any messages in the error log. -C ___ 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 )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Matt Hamilton wrote: Just to add myself to the list, I too am having problems with CoreSessionTracking :( I am trying to find a test case for the problem, but I really can't replicate it. It first I thought it was a cookie issue, but I am now noting down the session id generated and it stays the same even when my session data is lost, so I don't think it is that. what I experience: I add an item to my shopping cart system and it shows up fine, all state is maintained. If I however leave the page and not touch anything for a couple of minutes and then reload the page, the cart is now empty. I know this is not that helpful, but I'm trying to tie it down myself! Bummer. How long is the session data container timeout set for? Are you sure you're just not exceeding the timeout? One thing that I do need to check though -- I am right in assuming I can insert complex objects into the SessionData right? I have an 'Order' class that amongst other things has a dict containing instances of a 'Product' class. The Order instance is stored in the SessionData. As I said it appears to work fine and I can add and delete items from my Order fine. Just it randomly looses it now and then. Yes, any sort of object can go into session data... there are some caveats documented in the helpfile (for instance, acquisition-wrapped objects shouldn't be stored in session data), but otherwise anything's game. - C ___ 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: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
On Fri, 25 May 2001, Chris McDonough wrote: Bummer. How long is the session data container timeout set for? Are you sure you're just not exceeding the timeout? The session timeout is 120 minutes. I am using an external SessionDataComainter stored in the normal undo-able ZODB (I'm not expecting that much traffic to it). Looking into it further I don't think it is a CST fault :) I think I have fixed the problem. It was me not setting _p_changed on an object with a dict after adding items to the dict. Hence the session wasn't being lost, just the conents of the cart itself were not very persistent :) I'll be able to confirm this later today. Yes, any sort of object can go into session data... there are some caveats documented in the helpfile (for instance, acquisition-wrapped objects shouldn't be stored in session data), but otherwise anything's game. I can't find anything about acquisition-wrapped objects in the helpfile, what is the problem with them? -Matt -- Matt Hamilton [EMAIL PROTECTED] Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Hosting | Web Design | Domain Names | Co-location | DB Integration ___ 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: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Matt Hamilton wrote: Looking into it further I don't think it is a CST fault :) I think I have fixed the problem. It was me not setting _p_changed on an object with a dict after adding items to the dict. Hence the session wasn't being lost, just the conents of the cart itself were not very persistent :) Gotcha... (I can't tell you how many times I've done that ;-) Yes, any sort of object can go into session data... there are some caveats documented in the helpfile (for instance, acquisition-wrapped objects shouldn't be stored in session data), but otherwise anything's game. I can't find anything about acquisition-wrapped objects in the helpfile, what is the problem with them? Eek, you're right. This is a funny situation. I had thought I had documented this. But first I need to figure out what to document. Maybe that's why I didn't. The ZODB in general does not like to store acquisition-wrapped objects. It's usually the case in CST that you're prevented from doing this by the fact that you're generally using a mounted storage, and acqusition-wrapped objects in the context of Zope usually contain object references from the main storage (raising the InvalidObjectReference error documented in the helpfile). However, in cases like yours, where you're using a session data container that's *in* the main storage, you'll get past that hurdle (because your objects can't/don't contain references to another database). But you *should* be prevented from storing acqusition-wrapped objects in any database because it doesn't make sense to preserve an acqusition wrapper anywhere, they're completely ephemeral. But of course I just tried it, and it didn't raise any error. ;-) Hee hee. This means one of two things: 1. ZODB was fixed at some point to unwrap acquisition-wrapped objects before putting them in storage. This is likely. I dimly remember something like this happening, although I can't find it documented in any HISTORY or CHANGES files (not altogether surprising). 2. ZODB is blithely storing acquistion wrappers. If the answer is 1, everything's fine, and ignore my claim about not being able to pass acquisition-wrapped objects into session storage. Know that if you move to a mounted database in the future, and your code passes in objects pulled out of main Zope storage to session storage, that code will likely break. If the answer is 2, everything's not so fine. I'll likely need to change the CST code to unwrap acquisition-wrapped objects before storing them, just to head potential problems off at the pass. I just did a preliminary test, and it appears that it *is* storing acquisition-wrapped objects. This is bad if it's true. :-( In the meantime, to be safe, before you store an object in session storage, unwrap it by getting its aq_base, e.g.: ob = getattr(ob, 'aq_base', on) or use the utility function aq_base from Acquistion to safely do the same: from Acquisition import aq_base ob = aq_base(ob) Ah the bugs keep on piling on over here, - C -Matt -- Matt Hamilton [EMAIL PROTECTED] Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Hosting | Web Design | Domain Names | Co-location | DB Integration ___ 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: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Chris McDonough wrote: If the answer is 2, everything's not so fine. I'll likely need to change the CST code to unwrap acquisition-wrapped objects before storing them, just to head potential problems off at the pass. I just did a preliminary test, and it appears that it *is* storing acquisition-wrapped objects. This is bad if it's true. :-( Note that I just changed CST to unwrap aq-wrapped objects just in case, because what little testing I've been able to do says that aquisition wrappers are being stored in ZODB. I'm sure someone's going to come along and tell me that's the dumbest thing they've ever heard, but the changes don't hurt anything if I'm wrong. The requisite changes to the SessionData class (in the SessionData.py module) are: from: def __setitem__(self, k, v): # if the key or value is a persistent instance, # set up its _p_jar immediately if hasattr(v, '_p_jar') and v._p_jar is None: v._p_jar = self._p_jar v._p_changed = 1 if hasattr(k, '_p_jar') and k._p_jar is None: k._p_jar = self._p_jar k._p_changed = 1 self._container[k] = v self._p_changed = 1 to: def __setitem__(self, k, v): # if the key or value is a persistent instance, # set up its _p_jar immediately if hasattr(v, '_p_jar') and v._p_jar is None: v._p_jar = self._p_jar v._p_changed = 1 if hasattr(k, '_p_jar') and k._p_jar is None: k._p_jar = self._p_jar k._p_changed = 1 # unwrap this thing if it's wrapped from Acquisition import aq_base k = aq_base(k) v = aq_base(v) self._container[k] = v self._p_changed = 1 weeping (although grateful for the exchange), - C ___ 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: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Chris McDonough wrote: To further try to track this problem down, I've developed a burger, fries, coke application in honor of this thread. So far, I've eaten 84 burgers, 31 cokes, and 42 fries. I can't seem to break this thing, and I'm not hungry anymore. :-( Sorry, but I had to :-) http://www.zopezen.org/Zope/Quotes *grinz* Chris ___ 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: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Chris McDonough wrote: Note that I just changed CST to unwrap aq-wrapped objects just in case, I always wondered why Squishdot did this, now I know :-) cheers, Chris ___ 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: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Chris McDonough:
[...]
weeping (although grateful for the exchange),
I'm sorry Chris. We didn't give you a very good debugging chase. I
know how frustrating bug reports like Help! It doesn't work is, but I
guess it's very hard to troubleshoot bugs in frameworks since there's so
much customized code in there.
To be a little bit more helpful I've included two functions:
cart_add(sku, qty) (Python Script)
This function adds qty amount of a skus (integer id for product
items) to the cart
cart_display (DTML Method)
This method displayes the cart
The bug appears even when these two functions are the only functions
interacting with the session and the shopping. There are obviously some
references to code not provided in there, so don't expect them to work
just like that. If you can't see anything wrong from a simple code
inspection, I volounteer to provide the whole site for you.
It's quite refreshing to do a project for a sandwich shop, like we do
now, but I hope we can get to the bottom of these disappearing cokes. :)
Thank you for all the help. Open source sure beats the heck out of
commercial solutions when it comes to support.
Bye,
--
Bjorn Stabell [EMAIL PROTECTED]
cart_add(sku, qty)
___
session = context.session_mgr.getSessionData()
cart = session.get('shopping_cart', {})
sku = int(sku)
if not cart.has_key(sku):
cart[sku] = 0
if int(qty)0:
cart[sku] = cart[sku] + int(qty)
session.set('shopping_cart', cart)
container.cart_recalculate()
context.REQUEST.RESPONSE.redirect(context.REQUEST['HTTP_REFERER'])
cart_show()
___
dtml-call REQUEST.set('totalprice',0)
dtml-comment
Session token key, value: dtml-var session_mgr.getTokenKey(),
dtml-var session_mgr.getToken()br
/dtml-comment
dtml-let cart=session_mgr.getSessionData().get('shopping_cart', {})
dtml-if cart.keys()
dtml-in cart.keys() sort
dtml-if sequence-start
table border=0 cellspacing=0 cellpadding=0 width=100%
tr
td bgcolor=#FFDAAB
form action=cart_change method=post
table width=100% border=0 cellspacing=1 cellpadding=2
align=center
tr
td colspan=2 bgcolor=#006633 class=pagetitledtml-var
gettext('Order Bag')/td
/tr
tr
tddtml-var gettext('Category')/td
td align=right width=20%dtml-var gettext('Qty')/td
/tr
/dtml-if sequence-start
dtml-let shop_item=get_shop_item(_['sequence-item'])
tr valign=top
td bgcolor=#FF
!--dtml-var shop_item.Description()--
dtml-var shop_item.Title()
a href=cart_rm?sku=dtml-sequence-item;dtml-var
gettext('remove')/a
dtml-comment
!--dtml-var shop_item.absolute_url() html_quote--
a href=cart_rm?sku=dtml-sequence-item;remove/a
!--dtml-var shop_item.price
/dtml-comment
dtml-let qty=_.int(cart[_['sequence-item']])
dtml-call REQUEST.set('totalprice', totalprice + shop_item.price *
qty)
/td
td nowrap bgcolor=#FFinput type=hidden name=skus:list
value=dtml-sequence-item;
input type=text name=sku_dtml-sequence-item;:int
value=dtml-var cart[_['sequence-item']] size=1
/td
/dtml-let
/dtml-let
/tr
dtml-if sequence-end
tr valign=top
td colspan=2 align=right class=RMB
bgcolor=#CCdtml-var gettext('TOTAL')
dtml-var
_.int(session_mgr.getSessionData().get('shopping_cart_amount', 0))
/td
/tr
tr valign=top
td colspan=2 bgcolor=#FF
bdtml-var gettext('Bonus points')/b br
dtml-var gettext('This order is worth') dtml-var
_.int(session_mgr.getSessionData().get('shopping_cart_bonus', 0))
br
dtml-unless portal_membership.isAnonymousUser()
dtml-var gettext('Bonus points to spend')
dtml-var _.int(member.bonus_points)
/dtml-unless
/td
/tr
tr valign=top
td colspan=2 bgcolor=#FF
input type=submit name=Submit value=dtml-var
gettext('update')
a href=orderFormdtml-var gettext('Checkout')/a /td
/tr
/table
/td
/tr
/table/dtml-if sequence-end
dtml-else
Empty
/dtml-in
/form
/dtml-if
/dtml-let
___
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 )
Brought to you live: The Bug (RE: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8))
By the way, Chris, you can see the bug in action at our site by going to: http://www.beijingsammies.com:7380/sammies/ The website has not been launched yet, so be careful guys. Also, don't try ordering, unless you're in Chaoyang district, Beijing, China. :) The site may be slow since it's hosted in China. Try adding some items to the shopping cart, and then clicking on the navigation menu, browsing the various brochureware pages (only cart_show is called; no modification is done). At some point, the shopping cart should suddenly disappear. If you continue browsing, it may appear again. Actually, if you add items to the shopping cart while it is disappeared/empty, they'll get accepted and you'll have two different shopping carts. Which one you see is random. The session objects are set up like this: /session_id_mgr (session id manager) /sammies/session_mgr(session data manager) There are no other session id or data managers. The session data manager is using the default internal RAM-based session data container with no onStart or onEnd methods. Here's the test run I just did: - I added a few items to the shopping cart - Then I clicked on different brochureware pages for about one hundred clicks (2 minutes? a trial in patience :) I managed to get the error: - The shopping cart became emptied - Checking the session data manager, it still showed one item/session - I added more items to the new, blank session - After about 30-40 clicks, it changed into the old session again I notice that this kind of 'change' OFTEN HAPPENS WHEN I CLICK A NEW LINK BEFORE THE OLD PAGE HAS LOADED COMPLETELY, i.e., I interrupt the page half-way. Sometimes I also think that I notice a delay in Zope (the requests seems to take one second longer) when this kind of switch happens, but that may be me imagining things. There's nothing unusual in the STUPID_LOG_FILE when the switch occurs. I can, however, see that the previous time we ran zope we had the errors I've attached below (shouldn't make any difference). Bye, -- Bjorn [...] -- 2001-05-25T07:41:03 ERROR(200) ZODB Couldn't load state for '\000\000\000\000\00 0\000)\247' Traceback (innermost last): File /zope/zope-dc-2.3.2/lib/python/ZODB/Connection.py, line 508, in setstate AttributeError: 'None' object has no attribute 'load' -- 2001-05-25T07:43:58 INFO(0) ApplicationManager Shutdown requested by jey -- 2001-05-25T07:43:58 ERROR(200) ZODB Couldn't load state for '\000\000\000\000\00 0\000)\247' Traceback (innermost last): File /zope/zope-dc-2.3.2/lib/python/ZODB/Connection.py, line 508, in setstate File /zope/zope-dc-2.3.2/lib/python/ZODB/FileStorage.py, line 595, in load (Object: /zope/site-cn:7300-sammies/var/Data.fs) File /zope/zope-dc-2.3.2/lib/python/ZODB/FileStorage.py, line 572, in _load (Object: /zope/site-cn:7300-sammies/var/Data.fs) ValueError: I/O operation on closed file -- 2001-05-25T07:43:58 PROBLEM(100) zdaemon zdaemon: Fri May 25 15:43:58 2001: The kid, 16615, died on me. -- 2001-05-25T07:47:23 INFO(0) zdaemon zdaemon: Fri May 25 15:47:23 2001: Houston, we have forked -- 2001-05-25T07:47:23 INFO(0) zdaemon zdaemon: Fri May 25 15:47:23 2001: Hi, I jus t forked off a kid: 18005 -- 2001-05-25T07:47:23 INFO(0) zdaemon zdaemon: Fri May 25 15:47:23 2001: Houston, we have forked -- 2001-05-25T07:47:27 INFO(0) ZServer HTTP server started at Fri May 25 15:47:27 2 001 Hostname: box.exoweb.net Port: 7380 -- 2001-05-25T07:47:27 INFO(0) ZServer FTP server started at Fri May 25 15:47:27 20 01 Hostname: box Port: 7321 ___ 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: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Nope, couldn't have been, because: I couldn't set _p_changed from Python
Script, but I changed the last line setting the shopping_cart object in
the session to:
session.set('shopping_cart', cart.copy())
This should create a fresh copy of the dict, which should be sufficent
notice for the persistence machinery (or isn't a shallow copy enough?
cart is a dict of integers). I also removed the call to
cart_recalculate, just to make sure there were no spooky thing going on
there. I'm still seeing the bug.
Just a quick question. In:
session.set('shopping_cart', cart)
is cart call-by-reference or call by value (cart is a dict). I guess it
depends if 'set' makes a copy of the dict or not before assignment?
Also, do I really have to make a copy, or is there a way from Python
Script to notify the persistence machinery about a change in a complex
object, e.g., dict?
Bye,
--
Bjorn
-Original Message-
From: Matt Hamilton [mailto:[EMAIL PROTECTED]]
Posted At: Saturday, May 26, 2001 00:37
Posted To: Zope Developer
Conversation: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Subject: RE: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
On Fri, 25 May 2001, Bjorn Stabell wrote:
session = context.session_mgr.getSessionData()
cart = session.get('shopping_cart', {})
sku = int(sku)
if not cart.has_key(sku):
cart[sku] = 0
if int(qty)0:
cart[sku] = cart[sku] + int(qty)
Could this be the same problem that I was experiencing, in that
dicts/btrees do not in themselves notify the persitence machinery that
they have changed? try adding cart._p_changed = 1 to the code after
modifying cart{}.
-Matt
--
Matt Hamilton [EMAIL PROTECTED]
uk
Netsight Internet Solutions, Ltd. Business Vision on the
Internet
http://www.netsight.co.uk +44 (0)117
9090901
Web Hosting | Web Design | Domain Names | Co-location | DB
Integration
___
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 )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Hi Joachim,
I'm confused as to the utility of this bit of code.
You loop over the items in the REQUEST.form dict, putting them all into
session storage except for 'file'.
Then you loop over all the items in the session data object, putting
them into the REQUEST.other dict.
Why the first step? What if I did:
http://yoursite/amethod?bag=YESfarb=FOO
I'd have both bag and farb in my session data object? Would this be
sufficient instead:
dtml-let data=SESSION.getSessionData()
manage=REQUEST.get('manage_content') or
data.get('manage_content')
dtml-unless manage
dtml-call data.set('manage_content','NO')
/dtml-unless
dtml-in data.keys()
dtml-let si=sequence-item
dtml-call REQUEST.set(si, data[si])
/dtml-let
/dtml-in
/dtml-let
I'm also confused why you're using YES and NO to represent a boolean
instead of just checking that a key exists or is true.
Aside from that, the code looks fine to me. Your problem is consistent
with Bjorn's iasmuch as it seems that your session data object gets
cleared inappropriately... but I can't make this happen on my copy of
Zope and CST. :-( Maybe after I look at Bjorn's site, I'll have a few
more clues. Bjorn also provided some additional data that is helpful as
well. I'll try to synthesize this stuff and come up with some sort of
answer next week (I'll be away for the weekend).
- C
Joachim Werner wrote:
I know, but that's why the errors are called random: They are not easy
to
replicate ...
I understand.
I don't know if this helps a bit: It's the code used in KONTENTOR for
putting the session into the REQUEST namespace. I think it is not the most
elegant way of doing this, but it seems to work, except for the times it
doesn't ;-)
The actual problem I can trace (we don't have a shopping cart) is that the
manage_content variable falls back to NO without a reason. Please tell me
that the problem is in our code, not in the CST:
dtml-let data=SESSION.getSessionData()
dtml-unless data.has_key('manage_content')
dtml-call data.set('manage_content','NO')
/dtml-unless
dtml-in REQUEST.form.keys()
dtml-let si=sequence-item
dtml-unless si=='file'
dtml-call data.set(si, REQUEST[si])
/dtml-unless
/dtml-let
/dtml-in
dtml-in data.keys()
dtml-let si=sequence-item
dtml-call REQUEST.set(si, data[si])
/dtml-let
/dtml-in
/dtml-let
Cheers
Joachim
___
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 )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
What we experience with CoreSessionTracking: We have a manage mode in the Kontentor CMS hacky thing (no, it is NOT a product yet ;-)). It works well for some time (i.e. if I click on it, the system switches to manage mode and stays in manage mode until I click again), but from time to time it is just reset (quite randomly, too) to the non-manage mode. The click just sets a session variable. Haven't got any deeper with it yet, but the session seems not to be really reliable ... Joachim ___ 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: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
These it appears CST is unstable reports are helpful to an extent (from Bjorn, Joachim, and Howard), as it lets me know that something needs to be done to CST. However, a much more helpful report would be one which provides a repeatable test case which invariably reproduces the problem instead of one which states the symptoms and effects of the problem. At this point, I understand that there *is* at least one problem, and I understand what constitutes the problem(s), but I can't seem to reproduce it/them. Since I'm not able to reliably reproduce the error state, I can't find the bugs, and this means I can't fix them. It doesn't help much that I have almost no time to devote to this at the moment, either. If anyone can come up with a repeatable test case which uses CST out of the box in a fresh Zope 2.3.X install which demonstrates this failure, I would be most grateful, and it would cause the problem to be fixed much faster! Shane has come up with a way to fix the None has no attribute 'load' bug that has plagued CST since the beginning, so maybe I'll make a release next week with the fix in it to see if the problems that are being reported are related to that. I will try some more stuff in the meantime, although I'm at a loss currently as to what could be causing these symptoms. :-( - C Joachim Werner wrote: What we experience with CoreSessionTracking: We have a manage mode in the Kontentor CMS hacky thing (no, it is NOT a product yet ;-)). It works well for some time (i.e. if I click on it, the system switches to manage mode and stays in manage mode until I click again), but from time to time it is just reset (quite randomly, too) to the non-manage mode. The click just sets a session variable. Haven't got any deeper with it yet, but the session seems not to be really reliable ... Joachim ___ 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 )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
On Thu, 24 May 2001, Chris McDonough wrote: These it appears CST is unstable reports are helpful to an extent (from Bjorn, Joachim, and Howard), as it lets me know that something needs to be done to CST. However, a much more helpful report would be one which provides a repeatable test case which invariably reproduces the problem instead of one which states the symptoms and effects of the problem. Just to add myself to the list, I too am having problems with CoreSessionTracking :( I am trying to find a test case for the problem, but I really can't replicate it. It first I thought it was a cookie issue, but I am now noting down the session id generated and it stays the same even when my session data is lost, so I don't think it is that. what I experience: I add an item to my shopping cart system and it shows up fine, all state is maintained. If I however leave the page and not touch anything for a couple of minutes and then reload the page, the cart is now empty. I know this is not that helpful, but I'm trying to tie it down myself! One thing that I do need to check though -- I am right in assuming I can insert complex objects into the SessionData right? I have an 'Order' class that amongst other things has a dict containing instances of a 'Product' class. The Order instance is stored in the SessionData. As I said it appears to work fine and I can add and delete items from my Order fine. Just it randomly looses it now and then. -Matt -- Matt Hamilton [EMAIL PROTECTED] Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Hosting | Web Design | Domain Names | Co-location | DB Integration ___ 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: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
However, a much more helpful report would be one which provides a repeatable test case which invariably reproduces the problem instead of one which states the symptoms and effects of the problem. I know, but that's why the errors are called random: They are not easy to replicate ... ___ 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: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Joachim Werner wrote: However, a much more helpful report would be one which provides a repeatable test case which invariably reproduces the problem instead of one which states the symptoms and effects of the problem. I know, but that's why the errors are called random: They are not easy to replicate ... I understand. I just wrote a test case that emulates many visitors firing off sessions and making changes to shared data objects simultaneously. It even emulates aborted connections. Unfortunately, I see nothing out of the ordinary. :-( This is very frustrating. - C ___ 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: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Chris McDonough wrote: I just wrote a test case that emulates many visitors firing off sessions and making changes to shared data objects simultaneously. It even emulates aborted connections. Unfortunately, I see nothing out of the ordinary. :-( This is very frustrating. Maybe the problem folks are experiencing with CST are related to the None has no attribute 'load' bug that pops up every so often using a mounted storage (RAM-based session data containers use a mounted storage internally). If there's any chance that you can turn the STUPID_LOG_FILE on, if the problem happens while you're using the site, it would be helpful to be able to correlate (or not correlate) the problems folks are having with any messages in the error log. -C ___ 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
Hi The problem about CoreSessionTracking we describe before we can repeat again now. The step is: ( 1 ) User adds Burger to shopping cart ( 2 ) User adds coke to shopping cart and click link to add coke again before request finished ( 3 ) The Burger is disappear in shopping cart and just one coke ( not two ) ( 4 ) Repeat the step 2,Burger is back Anything you could tell me would be helpful. Regards, howard ___ 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
I remember this problem, but I haven't been able to reproduce it. But maybe it's because I'm not understanding the steps to reproduce it. The sentence user adds coke to shopping cart and click link to add coke again before request finished is hard to understand. Can you explain? Are you using frames? Howard Zhang wrote: Hi The problem about CoreSessionTracking we describe before we can repeat again now. The step is: ( 1 ) User adds Burger to shopping cart ( 2 ) User adds coke to shopping cart and click link to add coke again before request finished ( 3 ) The Burger is disappear in shopping cart and just one coke ( not two ) ( 4 ) Repeat the step 2,Burger is back Anything you could tell me would be helpful. Regards, howard ___ 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 )
Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Allright, let me try again. I wish I had a small piece of code to give you so you can reproduce it, but right now you'd have to get our entire CMF-based website. The bug basically manifests itself in that there are two versions of the variable we put in the session (a shopping cart dict). When I browse through the site (not even updating the shopping cart) it'll show one version for some links (1-40) before it switches to show the other, and so on. It looks like the website has two shopping carts that it switches back and forth between. You can see the shopping cart on every page in the website (it's embedded into the template). We were using frames, but I tried it several times without frames now and the bug remains. I even noticed that other variables disappeared randomly as well, e.g., USER_PREF_LANGUAGES which is set by the Localizer, resulting in a key error (I've probably seen 300 pages views, and then suddenly one going back to another page gives a key error?). I'm very curious what could possibly be causing such problems. I thought there might be something wrong in the shared memory between threads, as I can't see anything else changing but the threads (is there a way to display which thread is doing the publishing?). I've seen similar randomness displayed in other situations where I've been reloading pages that would sometimes (same interval, about every 1-40 times) show one character set, and other times another. I think nobody likes to see that kind of randomness. It gives me a very bad stomach feeling. I definately think it's something deeper than a CoreSessionTracking problem. Bye, -- Bjorn Stabell [EMAIL PROTECTED] -Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 23, 2001 20:34 To: Howard Zhang Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Exoweb Subject: Re: [Zope-dev] CoreSessionTracking 0.8 I remember this problem, but I haven't been able to reproduce it. But maybe it's because I'm not understanding the steps to reproduce it. The sentence user adds coke to shopping cart and click link to add coke again before request finished is hard to understand. Can you explain? Are you using frames? Howard Zhang wrote: Hi The problem about CoreSessionTracking we describe before we can repeat again now. The step is: ( 1 ) User adds Burger to shopping cart ( 2 ) User adds coke to shopping cart and click link to add coke again before request finished ( 3 ) The Burger is disappear in shopping cart and just one coke ( not two ) ( 4 ) Repeat the step 2,Burger is back Anything you could tell me would be helpful. Regards, howard ___ 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 )
RE: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
It's obvious. This is just Zope's way of telling you not live on hamburgers and coke. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bjorn Stabell Sent: Thursday, May 24, 2001 12:33 AM To: Chris McDonough; Howard Zhang Cc: [EMAIL PROTECTED] Subject: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8) Allright, let me try again. I wish I had a small piece of code to give you so you can reproduce it, but right now you'd have to get our entire CMF-based website. The bug basically manifests itself in that there are two versions of the variable we put in the session (a shopping cart dict). When I browse through the site (not even updating the shopping cart) it'll show one version for some links (1-40) before it switches to show the other, and so on. It looks like the website has two shopping carts that it switches back and forth between. You can see the shopping cart on every page in the website (it's embedded into the template). We were using frames, but I tried it several times without frames now and the bug remains. I even noticed that other variables disappeared randomly as well, e.g., USER_PREF_LANGUAGES which is set by the Localizer, resulting in a key error (I've probably seen 300 pages views, and then suddenly one going back to another page gives a key error?). I'm very curious what could possibly be causing such problems. I thought there might be something wrong in the shared memory between threads, as I can't see anything else changing but the threads (is there a way to display which thread is doing the publishing?). I've seen similar randomness displayed in other situations where I've been reloading pages that would sometimes (same interval, about every 1-40 times) show one character set, and other times another. I think nobody likes to see that kind of randomness. It gives me a very bad stomach feeling. I definately think it's something deeper than a CoreSessionTracking problem. Bye, -- Bjorn Stabell [EMAIL PROTECTED] -Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 23, 2001 20:34 To: Howard Zhang Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Exoweb Subject: Re: [Zope-dev] CoreSessionTracking 0.8 I remember this problem, but I haven't been able to reproduce it. But maybe it's because I'm not understanding the steps to reproduce it. The sentence user adds coke to shopping cart and click link to add coke again before request finished is hard to understand. Can you explain? Are you using frames? Howard Zhang wrote: Hi The problem about CoreSessionTracking we describe before we can repeat again now. The step is: ( 1 ) User adds Burger to shopping cart ( 2 ) User adds coke to shopping cart and click link to add coke again before request finished ( 3 ) The Burger is disappear in shopping cart and just one coke ( not two ) ( 4 ) Repeat the step 2,Burger is back Anything you could tell me would be helpful. Regards, howard ___ 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 ) winmail.dat
Re: [Zope-dev] CoreSessionTracking 0.8
On 23 May 2001 19:00:41 +0800, Howard Zhang wrote:
Hi
The problem about CoreSessionTracking we describe before we can
repeat again now.
The step is:
( 1 ) User adds Burger to shopping cart
( 2 ) User adds coke to shopping cart and click link to add coke
again before request finished
( 3 ) The Burger is disappear in shopping cart and just one coke
( not two )
( 4 ) Repeat the step 2,Burger is back
dtml-call putTongueInObject('cheek')
Your server is starving, let it get it's fill and feed it regularly.
Quit taking the food away from it. ;)
.
___
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
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 )
