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

[Chris McDonough]

On Wed, 2004-09-08 at 14:12, Tim Peters wrote:
> IIRC, the last time this general area came up was:
> 
>     "API for dooming a transaction for ZODB 3.3"
>     http://mail.zope.org/pipermail/zodb-dev/2004-January/006414.html

Thanks!

> After growing some complications, it seemed to fizzle out.  It's still
> relevant, though, because the current thread seems to be retracing its steps
> <wink>.

I suspect this one is going to fizzle out too.  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.

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), I'm not sure what to do.

I'm not interested in rearchitecting ZODB 3.2 to have registerable
transaction managers.  OTOH, it seems that doing nothing may wind up
causing Zope users to experience impossible-to-track-down data
inconsistencies in sessions.  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), 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. ;-)

- C