[Zope-CMF] Re: cmfuid

[Michael Dunstan]

On 24/11/2004, at 10:40, Chris McDonough wrote:

> On Tue, 2004-11-23 at 12:33, Gregoire Weber wrote:
>> Hi Chris,
>>
>>
>>> Here's what happens in the pathological case (broken down by "time
>>> units):
>>>
>>> time 0: counter is at 0
>>>
>>> time 1: thread 1 changes the counter during a new uid call,
>>>        the generated uid is 1
>>>
>>> time 1: thread 2 changes the counter during a new uid call
>>>        the generated uid is 1
>>>
>>> (note that no conflicts have happened yet, write conflicts are only
>>> raised at commit time and read conflicts don't happen because the 
>>> Length
>>> object is _p_independent)
>>>
>>> time 2: thread 1 commits
>>>
>>> time 3: thread 2 commits, but commit generates a write conflict
>>>        due to thread 1 being generated beforehand.  The write
>>>        conflict for the counter is resolved and it is set to 2.
>>>
>>> Note that the counter is indeed correct (it's now 2, the next uid 
>>> handed
>>> out will be 3) but we've handed out the uid "1" twice.  We resolved 
>>> the
>>> write conflict on the Length object at commit time but it didn't help
>>> us.  Both threads committed after giving two different callers the 
>>> same
>>> uid, so we presumably now have two objects with the same "uid" value,
>>> which is not desirable.
>>
>> Oh dear, now I see it!
>>
>> I hoped the BTree.Length would manage everything for us ... (but I 
>> know by
>> experience that when you think like this the alarm bell shall bell).
>>
>> So the fast solution for now is to have a hot spot (counter) ...
>
> A simple integer counter will probably work for Zope 2.7 (at great
> expense for applications that have a lot of uid-generation concurrency;
> it's arguable that there are many of these, however).
>
> But the more I think about it, I realize that the simple counter will
> fail to work properly under 2.8 with MVCC.  I *think* it will exhibit
> the above symptom for a different reason, unless there is a facility to
> override what happens when read conflicts occur (and thus MVCC kicks 
> in)
> within ZODB 3.3.  I don't know that there isn't such a thing, but I've
> not heard of it.  AFAIK, the MVCC behavior when "resolving" a read
> conflict is hardwired.

But a write conflict will still be raised if there is any transaction 
concurrency because counter needs to be updated? So the simple counter 
should work for ZODB 3.3 too.

Michael