[Zope] RE: CST and disappearing variables (still)

sean.upton@uniontrib.com sean.upton@uniontrib.com
Wed, 03 Oct 2001 10:25:44 -0700


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 )