[ZODB-Dev] ZODB packing error

[Toby Dickenson]

On Monday 05 April 2004 21:59, Tim Peters wrote:
> I expect the outcome depends on the details of the conflict resolution
> implemented by O.  If, e.g., O is a BTree, the removal of P (maybe that's
> one of O's keys) probably wouldn't raise a ConflictError.  But in that
> case, P would also be removed from the final (post-resolution) committed
> state, so no dangling reference either.

It is obviously possible to contrive a conflict resolution method which causes 
a dangling reference by ignoring the change made in the first transaction. It 
would be a bug for the BTree conflict resolution method to do this....  but 
are there any cases where this would not be a bug? Does zodb need to support 
this?

Previously Jim has argued no. At the time I wasnt conviced, but Ive never seen 
a counterexample. 

> Let me try to construct an actual dangling reference ... 
<snip>
> Back to the second client:
> >>> conn.sync()
> >>> O[2] = P      # this client still has a ref to P in memory
> >>> get_transaction().commit()  # and adds it to the BTree
> >>> st.close()

You stored a reference to a persistent object across transaction boundaries. I 
dont think we have ever declared whether or not this is permitted. To me it 
smells deeply dangerous, and there are several places where Zope goes to 
lengths to avoid doing this. For a start, youve lost your I from ACID.

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.


Do we have any causes of 0-day-pack losses that are not arguably application 
bugs?

-- 
Toby Dickenson