[ZODB-Dev] rasing a ReadConflictError

[Tim Peters]

[Tim Peters]
> [Michael Dunstan]
> ...
> Connection raises ReadConflictError in at least 3 places, so it's unclear
> why you're changing only one of them.  In one of those cases
> (_handle_independent), it does not add the oid to _conflicts; it's
> unclear whether that's a bug or a feature, ...

FYI, it's a bug.  If you get a ReadConflictError when loading an object with
a _p_independent() method that returns false(!), ZODB will let you commit
the transaction anyway (it *intends* to prevent committing any transaction
in which a ReadConflictError occurred).  I'm testing a fix and will check
that in later tonight.  Aaarghgh ... the same bug is in ZODB 3.3 too; may
not get to that one tonight.

> ...
> In the other case (commit()):
>
>         if self._conflicts.has_key(oid):
>             self.getTransaction().register(object)
>             raise ReadConflictError(object=object)
>
> oid is already in _conflicts, so no need to add it.  But it's hard (for
> me, anyway) to imagine why it's registering object here -- that is, how
> on Earth could we have gotten into commit() if the object wasn't already
> registered with the transaction?

I removed the call to register() here, and checked that in on the 2.7
branch.  The call was already gone in ZODB 3.3.

> Etc.  Every line of code you touch here blossoms into an exponentially
> growing number of mysteries <0.8 wink>.

Now that it's back down to sub-exponential, I suppose it's time to
complicate it again.