Am Freitag, den 01.06.2007, 09:47 +0200 schrieb Kai Diefenbach:
> Hi, 
> 
> After reading some documentation about transactions, concurrency and
> atomicity, I don't think that the following issue is a problem, but I'd
> be nice to get confirmation from some exports. Or - of course - that it
> doesn't behave in the way I think.
> 
> Within an adapter I increase a counter (e.g. for every download of an
> file) by doing: 
>         
>         self.counter[0] += 1
> 
> self.counter is a PersistentList stored as annotation.
> 
> Could there be a problem with concurrent access to the counter? With
> other words:
> 
> A gets counter = 5
> B gets counter (before A writes the increased counter) = 5
> 
> A increases and writes the counter => 6 
> B increases and writes the counter => 6 (*)
> 
> *) In my understanding, here a ConflictError is raised and the whole
> transaction will be repeated, that means it starts with the counter of
> 6. Is this right?

Yes, in Zope. That's nothing ZODB does. ZODB only raises a conflict
error and aborts the transaction.

And you can make it perform better by implementing application level
conflict resolution so your counter knows that if two transactions moved
from 5 to 6 concurrently the real value should be 7. This is *the*
example for when application level conflict resolution is helpful.

But: Your ALC code must be available on the ZEO server if needed.

Christian

-- 
gocept gmbh & co. kg - forsterstra├če 29 - 06112 halle/saale - germany
www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

Reply via email to