[ZODB-Dev] RE: [Zope-Annce] ZODB 3.2.4 release candidate 1released

[Chris McDonough]

On Mon, 2004-09-13 at 17:44, Tim Peters wrote:
> > So of these, it looks like only POSKeyError is something that feels like
> > ZODB should manage stickiness for (because it's difficult to predict when
> > it will occur).
> 
> POSKeyError should never occur.  

That's why when I notice that it happened I ignore it.

> > But it's raised in a lot of places that doesn't have access to the
> > current transaction. :-(  Maybe worse is that it subclasses
> > KeyError (having an except KeyError: in Zope is quite common and has
> > heretofore been deemed "safe"), so a developer could think his code was
> > perfect and still get hosed.
> 
> Ewww -- hadn't thought of that.  So it's a doubly good thing that
> POSKeyError is impossible <wink>.

I'm not sure if you're joking or not.  I think you're not -- but the
placement of the wink is a little ambiguous.

> > 3.2's Connection.py raises a whole slew of errors but it seems to have
> > access to the transaction at all times as an instance attr.  Or at least
> > it pretends to.
> 
> Yes, 3.2 Connection has to know the current transaction, because modified
> objects are registered with the transaction in 3.2 (see
> Connection.register).  In 3.3, Connections keep track of their own modified
> objects, but the transaction manager the Connection should use is passed to
> DB.open(); because resource managers (like Connections) "join" transactions
> in 3.3, Connection still needs to know this.
> 
> > I'm sure other fun exists in the other storages.  But if we could get
> > stickiness in place for "unpredictable" raises (I realize that's a
> > squishy term) from FileStorage, temporarystorage, Connection, DB and
> > utility modules, it might head off some potential data problems caused by
> > inappropriate exception handling.  Do you think it is worth it?  I could
> > help.  I think. ;-)
> 
> I think it may be worth it if it starts with the 2.8 line.  Trying to keep
> multiple versions healthy is a horrendous drag on making improvements (like,
> e.g., adding savepoints, or support for multiple database connections -- or
> even this!).

Fair enough.  I will take a stab at stickiness for various things on a
branch of 3.3 then... if I can find it. ;-)

> [... sorry for cutting things out, but I'm spending way too much time
>      staring at email today ...]

Of course... I appreciate your responses as always.

> >> Indeed, if a dict lookup triggers a ReadConflictError or POSKeyError
> >> (or anything else), the same thing can happen; PyDict_GetItem()
> >> suppresses all exceptions now.
> 
> > Wow.  I wonder how likely a codepath that is.  It doesn't seem like an
> > RCE or PKE would be raised in the course of PyDict_GetItem() because the
> > dict it was operating against would already be unghosted and isn't its
> > own persistent object anyway, right?
> 
> The potential problem is that dict key comparison can invoke arbitrary
> Python code.  You'd have to be certifiably insane to, e.g., use a persistent
> object as a dict key, but that doesn't mean it can't happen.  Objects of any
> user-defined type, persistent or not, could try to do something with
> persistent objects in a __cmp__ or __eq__ method, and dict lookup may have
> to invoke one of those.

As Tres would say, that Deserves To Lose.  Pfft.  The next thing you
know, somebody will come along and have the unmitigated gall to use
*hasattr*. ;-)

- C