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

[Shane Hathaway]

On Thursday 09 September 2004 23:00 pm, Tim Peters wrote:
> The point is that *any* exception occurring in the pile of code will leave
> some number of the pile's trailing statements unexecuted, so that the
> persistent state is really unknown at commit() time.  I think the same
> argument applies exactly to Florent's example:  what's so special about
> ConflictError?

My thoughts exactly.  ConflictErrors don't bother me specifically, but 
singling them out bothers me.  Today, any sort of greedy exception handling 
has a pretty good potential to mess up the database.  ConflictErrors are the 
historical offenders and that's why they get all the attention.

> > transactions should not start implicitly in Zope.  After you commit or
> > abort a transaction,
>
> What if you try to commit() but the commit fails?  Same deal, right?  Do
> commit and abort there include the cases of subtransaction commit and abort
> too?  I'm assuming they do.

Probably.

> > the object system should be frozen until you explicitly begin the next
> > transaction with get_transaction().begin().  Attempts to change objects
> > between transactions should result in an immediate exception.
>
> Here I read the last sentence as expanding on "frozen"'s intended meaning,
> rather than as a requirement in addition to frozenness.  If that wasn't
> your intent, holler.
>
> Do you think "an attempt to transition an object to the changed state
> raises an exception" would be an accurate implementation of frozenness? 
> Maybe not, cuz that would still let changes occur in memory, it would just
> prevent modified objects from getting *marked* as being changed!  That
> sounds less like a cure than like a new disaster <wink>.

Well, here's what I had in mind.  The offending call to Connection.register() 
should ghostify the object.  Alternatively, the object should be added to a 
Connection-managed list of objects to ghostify at the start of the next 
transaction.

I suppose that implementation could lead to difficulties, though; it might 
break C code that doesn't expect objects to be ghosted so soon.  So maybe 
when objects are changed outside transaction bounaries, it's enough to set 
_p_changed like today, but throw an exception immediately, then abort the 
change at the beginning of the next transaction.  It should be simpler than 
what I first suggested.

> Because of those, I confess I just don't get the continued fretting over
> conflict errors specifically.  It is the case that a suppressed exception
> *during* commit() (subtransaction or not) magically starts a new
> transaction now, and that makes me shiver all over. That's been actively 
> discussed on zodb-dev over the last two days.

Strangely, my MTA didn't receive that part of the discussion until after I got 
into the discussion.  I'm behind the times. :-)

> Dieter doesn't seem to think 
> there's anything dubious about that behavior.  Do you think it would help
> if a failing commit did not magically start a new transaction, but
> guaranteed additional commits would continue to fail until an explicit
> begin() or abort()?

Yes, I think that would help.

> > As a bonus, code that accidentally writes between HTTP requests will
> > expose itself.
>
> What does "write" mean to you?  Is it just that a persistent object gets
> modified in memory, or does "write" also require that the modification get
> committed?

I intended the first meaning.  I should have said "accidentally changes 
persistent objects."

Shane