[ZODB-Dev] preventing a transaction from committing within appcode

[Tim Peters]

[Chris McDonough]
...
> I suspect this one is going to fizzle out too.

Most do; there are way more backed-up ideas than workers here.

> The best suggestion so far (Jeremy's) only really seems feasible for
> ZODB 3.3. That will likely not show up in a Zope 2 release before the
> heat death of the sun (or a year, whichever comes first ;-), so it's
> not very useful for the current crop of Zopes.  I'd be fine with
> volunteering implement Jeremy's suggestion for 2.8 but it won't help
> the hoi polloi in the meantime.

It's a(nother) reason for people to get more serious about 2.8, though.

> Given that folks seem to be resistant to providing an API to the cheap
> way of "dooming" a transaction (which fooling the Connection into
> thinking a read conflict happened, which has the side effect of dooming
> it),

Fooling a Connection doesn't actually accomplish anything, unless a specific
object R is also registered with the current transaction, where R._p_jar is
the Connection being fooled.  So if the real desire is to mark a Transaction
as doomed, going thru a Connection to do so is indirect and so also obscure
and brittle.

> I'm not sure what to do.

Call abort() a lot <wink>.

> I'm not interested in rearchitecting ZODB 3.2 to have registerable
> transaction managers.

Feature development on 3.2 stopped with 3.2 final.
 
> OTOH, it seems that doing nothing may wind up causing Zope users to
> experience impossible-to-track-down data inconsistencies in sessions.

Are they still occurring?

> I've had my fill of those. ;-)
>
> Assuming there really is a problem (I should really write a test case
> that attempts to proves so),

See "are they still occurring?" <wink>.

> the worst case scenario is that my app code
> sets self._p_jar._conflicts[self._p_oid] = 1 and I deal with
> implementation changes as they happen.  Works for me. ;-)

As above, that won't help unless self is registered with the current
transaction too.  Alas, there's no API to determine whether self is
registered with the current transaction.  That *normally* happens only if
self is modified (not just loaded).  That may be relevant because there
seems to be an implicit assumption in the code that an object registers with
a transaction exactly 0 or 1 times.  I don't know what might happen if an
object registers with a transaction more than once; maybe nothing; maybe new
kinds of data inconsistencies.  So you have to register the object with the
transaction if and only if it hasn't already registered with the
transaction.  I suppose it might work to guess that R has not registered
with the transaction iff R._p_changed is false, and R hasn't already been
registered with the transaction via this new back door.