Re: [ZODB-Dev] Re: Multi-Threading Transactions
--On 13. Oktober 2005 02:44:34 -0400 Chris Spencer [EMAIL PROTECTED] wrote: I understand that, but my point was when you call transaction.commit(), you don't necessarily know what you're committing. One thread may be ready to commit. Another may not be. If one thread calls transaction.abort(), they may be aborting changes made by another thread. You'd have to write a complicated coordination mechanism to handle multi-threaded transactions to be sure. If threading is limited to connections, then wouldn't in make sense if transactions were as well? I have no idea what you mean. Once again: when you are using multiple threads to write to the ZODB (as Zope does all the time) then usually every request is done with a dedicated transaction. The work within the threads happens isolated. Only at commit time an error might occurs when multiple thread write to the *same* object or one writes and one reads (already solved by using MVCC in Zope 2.8). NO idea what you mean by complicated coordination. Hopefully you don't write code that spawns up threads that deal will the ZODB in an insane way. This is tricky and you should really know what you are doing in this casethis is for experienced developers only -aj pgpOG6TpLHYjw.pgp Description: PGP signature ___ 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
Re: [ZODB-Dev] Re: Multi-Threading Transactions
Chris Spencer wrote: I understand that, but my point was when you call transaction.commit(), you don't necessarily know what you're committing. Yes you do, each thread has its own connection to the database, and this connection has an independent view of the database from any other thread. Calling commit on one connection does squat on any other connections ;-) Now, unless you're writing your own threading code, or your own connection code, you don't need to worry 'cos Zope does the right thing. If you are writing your own threading or connection code, you're either god-like, or an idiot. 99.5% percent of people who _think_ they need to write connection or threading code fall into the latter category... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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
Re: [ZODB-Dev] Re: Multi-Threading Transactions
On 10/13/05, Chris Spencer [EMAIL PROTECTED] wrote: I understand that, but my point was when you call transaction.commit(), you don't necessarily know what you're committing. One thread may be ready to commit. Another may not be. If one thread calls transaction.abort(), they may be aborting changes made by another thread. You'd have to write a complicated coordination mechanism to handle multi-threaded transactions to be sure. If threading is limited to connections, then wouldn't in make sense if transactions were as well? 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. Jeremy ___ 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
Re: [ZODB-Dev] Re: Multi-Threading Transactions
[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
