[Zope-CMF] Re: cmfuid

[Gregoire Weber]

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) ...


>Making _p_independent of the Length object return false will cause a
>read conflict to be generated at the time of uid generation (during
>"change") if two threads ask for a uid simultaneously.  This has the
>effect at least under Zope 2.7 of causing actually unique ids to be
>generated.  This doesn't work under 2.8.  Under 2.8, MVCC begins to kick
>in and we have the same problem again even if we override
>_p_independent.

I have to think more about that later (when I have more time).
But am I right that the current solution would be ok for Zope 2.8 with 
MVCC? 

Anyway, before the whole MVCC discussion arised I thought the
ZODB is already MVCC capable.

>I think it is a real problem, but I'm not sure of the best way to fix
>it.  I'd just use a probabilistic generator but Tres doesn't like them,
>I think.  I don't yet understand why, but I'm sure there's a good reason
>(Tres is right about 99.3% of the time ;-).

Hehe!


>No, although presumably it would be pretty simple to make it do so, I'd
>just steal the code from Python 2.4.

There will be a UUID implementation in Python 2.4?


>> I would propose here (after having corrected the counter issue) to add 
>> a new generator tool which users can use to replace the standard one.
>
>I'm not sure we need two default id generators, but I'll do whatever
>anybody wants done.

Just an idea:

A possible solution may be to have uids and uuids in parallel. Just
appending every new uuid to a registry (IOBTree) and then take the index 
as a "counter uid" (for Tres and me). 

May we run into problems with conflict errors this way?

Gregoire