[ZODB-Dev] ZODB packing error

[Toby Dickenson]

On Thursday 22 April 2004 04:15, Tim Peters wrote:

> > For a start, you've lost
> > your I from ACID.
>
> Sorry, I don't follow.  Seems to me the new transaction that implicitly
> began after the first commit() is as isolated as the transaction that did
> the first commit().  Maybe that's wrong.

The knowledge of the exististance of that object has leaked from the first 
transaction to the second. In the second transaction that object does not 
really exist.

Maybe I am demonstrating my storage-centric view here, by declaring that this 
object "does not really exist" despite the fact that we have a perfect 
in-memory copy of it.

> > I think I would like to declare this unsupported, but Im not entirely
> > comfortable with that either. As Tim demonstrated, it is _so_ easy to
> > do.
>
> I would like ZODB to detect dangling references at commit() time, and raise
> a subclass of ConflictError then.

DirectoryStorage raises DanglingReferenceError, a subclass of TransactionError 
not ConflictError. This reflects my belief that they should raise alarm 
bells, not be retried and masked.

>  DirectoryStorage does do so, right?

The dangling reference checking was designed to cover the case where the 
storage has never seen an object being referenced (for example, a 
hypothetical bug in the Connection might cause it to not record all newly 
created objects.)

Currently DirectoryStorage suffers from a race similar to that in FileStorage 
when there are concurrent packs; It is possible for this type of bad 
transaction (that is, one containing references to an object that it should 
not be accessible, created by copying a reference loaded from a previous 
transaction) to remain undetected if it commits while the referenced object 
still exists but its removal from disk is imminent.

Letting a few through undetected is adequate if (and only if) we declare that 
the underlying causes of these are all application bugs. They still get 
detected soon enough.

-- 
Toby Dickenson