[Zope-dev] Re: Sessions and long requests = conflicts? Mcdutils?

[Maciej Wisniowski]

> I dropped further development on it
> once I evaluated the cost of having session data disappear (or become
> inaccessible) when new memcache servers were added, or old ones removed.
Thanks for clearing that.
>
> If you are *sharing* mutable session data between multiple long-running
> requests, and expect to have no conflicts, you are in for a
> disappointment:  unless your application can supply resolution logic,
> you *want* conflict errors in such cases.
I'm not sharing session data between requests. I have two disctinct requests
(eg. from different browsers) and I expect them to have it's own session
objects. So if request 1 puts something into it's session I would expect
that it has nothing to second request's session, but this is not always
true
(I think when new timeslice appeared meanwhile). More, it is not even
necessary to change session data! Even just calling self.REQUEST.SESSION
causes conflicts.

Simple test I did is to create external method like:

import time
def testme(self):
    print 'testme started'
    self.REQUEST.SESSION
    time.sleep(5)
    print 'testme after sleep'
    return 'finished'

and call this manually from two different browsers.
It DOESN'T change session data!
I have Zope 2.9 instance with default setting of 
session resolution seconds == 20. I started
zopectl fg with logger level set to debug. after calling
my external method I see output like below:


#####  Default Zope session: I entered localhost:8081/testme from two
browsers ##########
2007-04-12 08:09:03 DEBUG txn.-1276576864 new transaction
testme started
2007-04-12 08:09:03 DEBUG txn.-1251398752 new transaction
testme started
testme after sleep
2007-04-12 08:09:08 DEBUG txn.-1276576864 commit <Connection at b588ea8c>
2007-04-12 08:09:08 DEBUG txn.-1276576864 commit
testme after sleep
2007-04-12 08:09:08 INFO ZPublisher.Conflict ConflictError at /testme:
database conflict error (oid 0x0d, class BTrees._OOBTree.OOBTree, serial
this txn started with 0x036ce3f0fca76611 2007-04-12 06:08:59.215758,
serial currently committed 0x036ce3f122de5f11 2007-04-12
06:09:08.172337) (1 conflicts (0 unresolved) since startup at Thu Apr 12
08:08:51 2007)
2007-04-12 08:09:09 DEBUG txn.-1251398752 abort
2007-04-12 08:09:09 DEBUG txn.-1251398752 new transaction
testme started
testme after sleep
2007-04-12 08:09:14 DEBUG txn.-1251398752 commit <Connection at b6307e8c>
2007-04-12 08:09:14 DEBUG txn.-1251398752 commit



##################################
With Faster (Resolution (seconds): 20) and time.sleep(5) in my external
method
I had no conflicts but after changing to time.sleep(25) I get:
##################################

2007-04-12 08:29:44 DEBUG txn.-1268184160 new transaction
testme started
2007-04-12 08:29:45 DEBUG txn.-1276576864 new transaction
testme started
testme after sleep
2007-04-12 08:30:09 DEBUG txn.-1268184160 commit <Connection at b588ea8c>
2007-04-12 08:30:09 DEBUG txn.-1268184160 commit
testme after sleep
2007-04-12 08:30:10 INFO ZPublisher.Conflict ConflictError at /testme:
database conflict error (oid 0x2d, class
Products.faster.sessiondata.SessionDataContainer, serial this txn
started with 0x036ce4051fa32844 2007-04-12 06:29:07.415000, serial
currently committed 0x036ce406266df400 2007-04-12 06:30:09.006915) (4
conflicts (0 unresolved) since startup at Thu Apr 12 08:08:51 2007)
2007-04-12 08:30:11 DEBUG txn.-1276576864 abort
2007-04-12 08:30:11 DEBUG txn.-1276576864 new transaction
testme started
testme after sleep
2007-04-12 08:30:36 DEBUG txn.-1276576864 commit <Connection at b6307e8c>
2007-04-12 08:30:36 DEBUG txn.-1276576864 commit


As you see there is even no change to session data from external method.

> If you believe that 'faster' is raising conflicts due its own internal
> data structures (OOBTree bucket splits), rather than in the
> application-dveined session data, there is a conflict-free alternative
> available:  we found that it was slower than the other, and therefore
> didn't scale as well, even given the possibility of conflicts.
Thanks for that clue.

-- 
Maciej Wisniowski