[ZODB-Dev] BTree set question

[John Belmonte]

Chris McDonough wrote:
> On Thu, 2004-02-26 at 08:55, John Belmonte wrote:
> 
>>Thanks very much, I'm glad I asked.  While the merge rules are as I 
>>hoped in the case of a set, I'm alarmed by the mapping value 
>>modification rule.  It's *not* conservative, and inconsistent (as you 
>>point out) with key insertion/deletion-- I consider it a bug.
> 
> Really?  Could you give an example of where you think this behavior
> might cause inconsistency?  It seems perfectly reasonable to me, and it
> would be nice if this happened on key insertion/deletion too.

Well, I said that the rules are inconsistent, not that they will cause 
an inconsistency in the database or something.  But I'll guess at your 
meaning and give a simple example of why the mapping value modification 
rule is dangerous.

Take a mapping of words to the number of times they were encountered. 
If transaction-A tries to increment count['idempotent'] by some amount, 
and transaction-B increments it by some amount, we get a write conflict 
as you'd hope-- except on the chance that they try to increment it by 
the same amount.

As Peter points out, you can probably accuse any such example of being 
bad design.  In this case the design problem is obvious.  However, it 
would be nice if we could write ZODB apps a little naively (or without 
having enough time to attend to all details on the first pass), and as 
the conflict errors crop up, design solutions for them.  This notion can 
be supported by having conservative BTree merge rules.  Code that is bad 
for ZODB, but otherwise perfectly "normal" if there wasn't concurrency, 
should generate write conflicts if reasonably possible.

-John


-- 
http:// if  ile.org/