[ZODB-Dev] Re: Concurrent transactions
Christian Theune [EMAIL PROTECTED] wrote: Am Freitag, den 01.06.2007, 09:47 +0200 schrieb Kai Diefenbach: 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. Ah, thanks! 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. Okay, sounds interesting. I check this out. Thanks! Kai -- Kai Diefenbach - http://diefenba.ch iqplusplus - http://iqpp.de ___ 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
[ZODB-Dev] Re: Concurrent transactions
Stefan H. Holek [EMAIL PROTECTED] wrote: Counting in the ZODB is more or less a no-go. You will get write conflicts, and your ZODB will grow (too) quickly. But what's an alternative? In general I don't like the thought to use a RDBMS in parallel to Zope's ZODB approach. And more than ever for a counter. That said, you may want to look at BTrees.Length for a counter with built-in conflict resolution. Looks good. Thanks for this hint. -- Kai Diefenbach - http://diefenba.ch iqplusplus - http://iqpp.de ___ 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
[ZODB-Dev] Re: Concurrent transactions
Jim Fulton [EMAIL PROTECTED] wrote: On Jun 1, 2007, at 6:07 AM, Kai Diefenbach wrote: Stefan H. Holek [EMAIL PROTECTED] wrote: Counting in the ZODB is more or less a no-go. You will get write conflicts, and your ZODB will grow (too) quickly. I kind of doubt that updating a little counter will make the database grow too quickly, but that might depend on how often the counter was updated and how you defined too. :) I didn't want to answer to Stefan before I tested this again. The first time I tested I remember that I didn't consider the growing of the db as to much. An issue with current ZODB storage implementations is that they require explicit packing to remove old revisions and, in the case of the file storage implementation, packing is rather expensive. (I think the FileStorage pack implementation could be improved quite a bit in this regard.) If you have a very busy counter, you might have to pack more often then you otherwise would. I see. But what's an alternative? That depends on the underlying use case. If you want to track traffic, there's always log analysis. :) As I think about that, this could be true for more uses cases as one might believe :-) Thanks Kai -- Kai Diefenbach - http://diefenba.ch iqplusplus - http://iqpp.de ___ 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
