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 += 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
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