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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Maciej Wisniowski wrote:
>> 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.
>>
>> To enable the conflict-free storage, you need to patch the
>> '_BUCKET_TYPE' class-level variable of the storage to use
>> 'AppendOnlyDict' rather than 'OOBTree'.  E.g.:
>>
>>   from Products.faster.sessiondata import CBSessionDataContainer
>>   from Products.faster.appendict import AppendOnlyDict
>>   CBSessionDataContainer._BUCKET_TYPE = AppendOnlyDict
>>
> I've changed to:
>  _BUCKET_TYPE = AppendOnlyDict
> 
> in sessiondata.py for SessionDataContainer and
> CBSessionDataContainer.
> 
> Unfortunatelly when I run external method like
> below concurrently from 3 different browsers
> (Opera, FF, Konqueror) I still get conflict errors.
> 
> import time
> def testme(self):
>     print 'testme started'
>     self.REQUEST.SESSION
>     time.sleep(50)
>     print 'testme after sleep'
>     return 'finished'

Did you configure the faster SDC to disable the 'lazy' flag?  That flag
disables modification of the SDC's linked list until the sesion is
actually modified, rather than being just accessed as you are doing here.

> Faster 'Resolution secs' is set to 20.
> Console output:
> 
> 2007-04-12 10:31:50 DEBUG txn.-1260708960 new transaction
> testme started
> 2007-04-12 10:31:51 DEBUG txn.-1277494368 new transaction
> testme started
> 2007-04-12 10:31:54 DEBUG txn.-1252316256 new transaction
> testme started
> testme after sleep
> 2007-04-12 10:32:40 DEBUG txn.-1260708960 commit <Connection at b562e9ac>
> 2007-04-12 10:32:40 DEBUG txn.-1260708960 commit
> testme after sleep
> 2007-04-12 10:32:41 INFO ZPublisher.Conflict ConflictError at /testme:
> database conflict error (oid 0x2b, class
> Products.faster.sessiondata.SessionDataContainer, serial this txn
> started with 0x036ce4767ce55799 2007-04-12 08:22:29.272469, serial
> currently committed 0x036ce480ad6d3044 2007-04-12 08:32:40.646840) (3
> conflicts (0 unresolved) since startup at Thu Apr 12 10:17:09 2007)
> 2007-04-12 10:32:41 DEBUG txn.-1277494368 abort
> 2007-04-12 10:32:41 DEBUG txn.-1277494368 new transaction
> testme started
> testme after sleep
> 2007-04-12 10:32:44 INFO ZPublisher.Conflict ConflictError at /testme:
> database conflict error (oid 0x2b, class
> Products.faster.sessiondata.SessionDataContainer, serial this txn
> started with 0x036ce4767ce55799 2007-04-12 08:22:29.272469, serial
> currently committed 0x036ce480ad6d3044 2007-04-12 08:32:40.646840) (4
> conflicts (0 unresolved) since startup at Thu Apr 12 10:17:09 2007)
> 2007-04-12 10:32:45 DEBUG txn.-1252316256 abort
> 2007-04-12 10:32:45 DEBUG txn.-1252316256 new transaction
> testme started
> testme after sleep
> 2007-04-12 10:33:31 DEBUG txn.-1277494368 commit <Connection at b62a8d8c>
> 2007-04-12 10:33:31 DEBUG txn.-1277494368 commit
> testme after sleep
> 2007-04-12 10:33:35 DEBUG txn.-1252316256 commit <Connection at b55b982c>
> 2007-04-12 10:33:35 DEBUG txn.-1252316256 commit
> 
> Also after few different tires, eg. with Resolution secs == 300 I
> ecountered conflicts with
> AppendOnlyDict like:
> 
> 2007-04-12 10:53:07 INFO ZPublisher.Conflict ConflictError at /testme:
> database conflict error (oid 0x4c, class
> Products.faster.appendict.AppendOnlyDict, serial this txn started with
> 0x036ce49409621366 2007-04-12 08:52:02.199166, serial currently
> committed 0x036ce49515ed0477 2007-04-12 08:53:05.138871) (9 conflicts (0
> unresolved) since startup at Thu Apr 12 10:17:09 2007)

That log message says you *are* modifying the AppendOnlyDict from
multiple transactions, and it is resolving those conflicts;  there are
therefore no retried or failed transactions here.

> Is there a point in faster where I can put debug message to see that
> bucket splits (or something like that) happened?

There are no bucket splits when using AOD.  You could put a
'pdb.set_trace()' inside its '_p_resolveConflicts' method, to see when
it was being called.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGHkPW+gerLs4ltQ4RAlfqAJ4zi+2IwUNV8AA9IT/K1revgMUwTQCfXxJ2
oJ9BfiRzIGcQZrUD1/sSwpQ=
=T5oL
-----END PGP SIGNATURE-----