[ZODB-Dev] Webkit Threading and ZODB 3.3a2: problems on Windows

[Matt Feifarek]

Tim Peters wrote:

>incomprehensible to most users.  It's mostly a matter of "common sense" that
>you close what you open, and finish what you start, in any kind of
>transactional system.
>  
>
I guess that's fair. We do close our connections; that makes sense. 
However, if we had seen a bunch of data written that we hadn't intended, 
we would have known that we "forgot to metaphorically close" something. 
Having it just stop accepting data for all future *conceptual* 
transactions doesn't really lead one to the conclusion that one forgot 
to commit in the past.

>BTW, what do you have in mind when you say "the docs"?  I'm curious to know
>  
>
http://zope.org/Wikis/ZODB/FrontPage/guide/index.html

It's a pretty good starter, but there's not much else.

>Well, as just above, it depends on everything else you're doing.  You're not
>*required* to either commit() or abort(), so it wouldn't be correct to say
>that you must do one of them.  I'm still not exactly sure what went wrong
>with your app, but it appeared to have more to do with not realizing that
>you *didn't* commit all the changes you thought you were committing, and
>then went on to reuse the thread for a different *conceptual* transaction,
>when in truth part of a previous conceptual transaction was still in limbo
>(neither commited nor aborted).  Then the disconnect is between what you
>thought you were doing and what you were actually doing, and that's pretty
>much the definition of "a bug" -- and that bugs can cause Bad Things to
>happen isn't unique to ZODB <wink>.
>  
>

I'm certainly admitting that we did something wrong; we made changes 
that we didn't know we were making, and then not aborting (or committing 
for that matter). That was our bug.

The thing is that once that happened, OTHER INTENDED OBJECT PERSISTENCE 
did not stick. It would make sense to me that our spurious writes would 
stick next time the transaction was re-used, but it doesn't make sense 
that the persistence is permanently broken, even if it's limited to a 
particular combination of thread/transaction/object. Our bug in touching 
objects shouldn't break the persistence. That's my point.

Basically, a bona-fide .commit() after a missing commit should still 
work. Even if it commits more than we intend. It's not working that way. 
I don't think that would fall under anyone's idea of common sense.

Also, maybe this is a beginner misconception here, but the idea that a 
"transaction" that stays live even after you CLOSE a connection does not 
seem like common sense.  I'm not familiar with other transactional 
systems, but I wouldn't expect that a pending transaction would survive 
the closing and destruction of a connection object. I now understand why 
it works that way, but only after everyone's education here.

Thanks.