[ZODB-Dev] Webkit Threading and ZODB 3.3a2: problems on Windows
Matt Feifarek
matt at dalchemy.com
Sun Feb 22 01:22:08 EST 2004
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.
More information about the ZODB-Dev
mailing list