Assuming you use a mounted non-undo storage and a Session Data Container, I assume that either the bsddb3 packless storage or the older db2-based non-undo Berkeley DB storage would be able to scale well enough to handle a container full of a bunch of sessions for quite a long time (days, weeks, months?), provided that your session id manager (cookie exp) and your data containers have synced expiration times. Sean -----Original Message----- From: Ron Bickers [mailto:rbickers-dated-1002723154.9433b4@logicetc.com] Sent: Wednesday, October 03, 2001 7:13 AM To: Chris McDonough Cc: Zope List Subject: RE: [Zope] RE: CST and disappearing variables (still)

-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Ron Bickers

I'll let you know when the problem shows up again.

Just got an empty cart, and the session log tells all. I'm a bit stunned, but maybe I shouldn't be. Users do strange things sometimes. 2001-10-02T18:54:30 INFO(0) Session START new token pyid 159677656 sid 40656853Az-57oGmXPc ip 24.88.58.162 2001-10-02T18:54:30 INFO(0) Session CALL (add [get]) new token pyid 146506488 sid 40656853Az-57oGmXPc len 0 cart None 2001-10-02T18:54:30 INFO(0) Session CALL (add [set]) new token pyid 147932800 sid 40656853Az-57oGmXPc len 0 cart None 2001-10-02T18:54:30 INFO(0) Session CALL (Items [get]) pyid 147444240 sid 40656853Az-57oGmXPc len 1 cart 1 2001-10-02T19:56:57 INFO(0) Session END sid 40656853Az-57oGmXPc 2001-10-03T13:40:19 INFO(0) Session START pyid 148619840 sid 40656853Az-57oGmXPc ip 24.88.58.162 2001-10-03T13:40:19 INFO(0) Session CALL (checkout [get]) pyid 143714000 sid 40656853Az-57oGmXPc len 0 cart None 2001-10-03T13:41:54 INFO(0) Session CALL (gatherCheckout [set]) pyid 143320024 sid 40656853Az-57oGmXPc len 0 cart None 2001-10-03T13:41:55 INFO(0) Session CALL (checkout [get]) pyid 143064448 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:02 INFO(0) Session CALL (gatherCheckout [set]) pyid 142953384 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:02 INFO(0) Session CALL (verify [get]) pyid 143623016 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:02 INFO(0) Session CALL (Items [get]) pyid 144859400 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:24 INFO(0) Session CALL (Items [get]) pyid 144859400 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:24 INFO(0) Session CALL (Items [get]) pyid 143947112 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:25 INFO(0) Session CALL (sendOrder [invalidate]) pyid 145079240 sid 40656853Az-57oGmXPc len 1 cart None 2001-10-03T13:47:25 INFO(0) Session END sid 40656853Az-57oGmXPc Here's how it went... 1) User adds item to their cart then goes to bed! 2) Session times out about an hour later as configured. 3) User sits down 19 hours later and selects "checkout" from a cart that still shows from yesterday but is really empty. 4) User fills out billing/shipping information. 5) User is *supposed* to verify their order at which point they should have noticed that the cart says it is *empty* right next to the "send order" link. 6) User doesn't bother paying attention. Instead, they send an empty order. I guess I should handle this in my application by not allowing it to be sent at the end when the cart is empty. They're already not allowed to checkout when the cart is empty, but I wrongly assumed the user would add items to their cart and checkout in the same sitting. That was stupid of me considering I just did a similar thing the other day. I wanted to "sleep on it" to make sure I got everything I needed in one shipment. In addition to fixing my application, is there any reason not to make the session timeout a large number, like 2 days? Thanks! _______________________ Ron Bickers Logic Etc, Inc. _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )