[ZODB-Dev] [ZODB4] - Shouldn't the new object be added to Connection._created ?

[Toby Dickenson]

On Monday 29 Jul 2002 10:33 am, Ury Marshak wrote:
> >> My app level code keeps the new object referenced, and then tries to
>
> rerun
>
> >> the transaction after fixing the conflict. As a workaround I could
>
> recreate
>
> >> the
> >> object if necessary,
> >
> >If the object was created in that (failed) transaction, then doesnt
> >reruning the transaction necessarily involve recreating the object?
>
> I don't know ;) That's one possible answer to my question - that this s=
ort
> of behavior is explicitly forbidden.

Its not forbidden; There are a couple of areas where Zope does this. Most=
=20
users dont notice the problems because it only bends this rule in unusual=
=20
circumstances; at startup, and when rendering an error page for example.=20
However it is definitely a danger area, and Zope sticks strictly to this =
rule=20
in normal operation.

> What I was actually trying to do was to write a class, say
> 'SequentiallyNumberedObject' that would have a method
> 'store_and_get_next_sequential_ID()', that would try to
> commit itself, and on a ConflictError it would bump up the ID
> number and try again. It seemed like a very convenient and
> nice design (at that point :)

After a ConflictError (or any other error that caused the transaction to=20
abort) that object is doomed. Throw away everything persistent if you wan=
t to=20
play safe.

I assume SequentiallyNumberedObject contains more than just a sequence=20
number...... Although you can not safely hold on to a reference to=20
SequentiallyNumberedObject across a transaction boundary, you can safely =
hold=20
on to a reference to some of its attributes for use in a subsequent retry=
=20
transaction.