[ZODB-Dev] _p_resolveConflicts

[JohnD.Heintz]

On Friday 03 August 2001 08:45, Chris Withers wrote:
> Jim Fulton wrote:
> > We check if the catalog already uses the id. If it does,
> > we pick another. We rely on consistency in the transaction system
> > to deal with concurrency.
>
> Ah, hence if you use the _p_independent trick you loose concurrency and
> hence the ids migth not be unique?

I think that the index (PersistentMapping, BTree) is the controller for=20
uniqueness in this case.  The _p_independent doesn't work here.

This is the code I imagine:
=2E..
newId =3D generate() # new random id
while index.has_key(newId):
=09newId =3D generate()
# now we should have a unique key on this Transaction/Connection
=2E..

and at commit time a conflict could be raised if two requests simultaneou=
sly=20
generated the same newId.  This shouldn't happen often and would simply b=
e=20
retried.

I think the "shouldn't happen often" part is the big win.  What I think y=
ou=20
and I were both asking for is a way to generate new unique ids without th=
e=20
cost of conflict retries.  We both thought that the conflict resolution m=
ight=20
hold the answer.

Jim is saying that this way of doing things will so seldomly generate=20
conflicts that we shouldn't need to worry about it hurting performance -=20
although it could still happen.

John

>
> cheers,
>
> Chris

--=20
=2E . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | jheintz@isogen.com

w w w . d a t a c h a n n e l . c o m