[ZODB-Dev] Webkit Threading and ZODB 3.3a2: problems on Windows
Tim Peters
tim at zope.com
Sat Feb 21 23:41:52 EST 2004
[Matt Feifarek]
> ...
> As a recent inductee to the ZODB world, I'd say we should get it into
> the docs that one must commit() or abort(), or Bad Things(r) will
> happen.
Probably, but the docs would have to be accurate <0.9 wink>. When you're
mucking with multiple threads, and multiple connections, and multiple
databases, and reusing threads across multiple transactions, it's plain
complicated, and I'm not sure I know what all "the rules" really are then.
Spell them all out, and the docs are likely to be both off-putting and
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.
BTW, what do you have in mind when you say "the docs"? I'm curious to know
what a relative newcomer discovered and looked at in the way of ZODB docs.
There are *partial* docs (for this and that) all over creation. Which did
find and read?
> We got the impression that changes (if any) are discarded if you don't
> .commit().
If you never commit, and your program ends, then it's true that whatever
changes your program made are discarded. OTOH, the changes you made remain
visible via the connection the changes were made on for the life of your
program. So it's some of each.
> It seems that it would be more correct to say that you must either
> commit or abort, or your data (and app) will become unstable.
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>.
More information about the ZODB-Dev
mailing list