[Jeremy]
> The default transaction manager maintains a separate
> transaction for each thread. When you call
> transaction.commit() from thread T1, it
> commits the transaction for thread T1. It has no effect
> on other thread's running transactions.
My apologies if this has been mentioned already (I'm
reading this via the Communigate interface, which as at
least Jeremy knows too well <wink> makes following a
discussion virtually impossible): the intended way to use
ZODB is to open a distinct Connection for each thread.
Then if, e.g., threads T1 and T2 both do
the_thread_Connection.root()['whatever'] = whatever2
T1 and T2 end up with distinct _in-memory_ copies of the
same persistent object. They don't interfere with each
other. Whichever thread commits first "wins". The second
thread to commit will get a (write) conflict error if both
threads modified the same persistent object, although
there's a possiblity to supply conflict resolution methods
too.
Chris, is this getting clearer? One thread == one
Connection == one transaction. The in-memory
materialization of a persistent object loaded from one
thread via its connection should _never_ be touched (or
even looked at) by any other thread. That last part is a
matter of programmer discipline, but is really quite easy
in practice. If the programmer doesn't go out of their way
to violate it, then each thread "naturally" sees its own
self-consistent view of database state, from its own
connection, and in its own transaction. The only point of
intersection is commit() time.
Now you can break that easy model by sharing in-memory
persistent objects across threads, or by trying to use a
single Connection in more than one thread. ZODB is not
intended to be used in such ways, and any number of bad
things will happen if you do them.
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
