[ZODB-Dev] [ZODB3.1] easily reproducible deadlock

Christian Robottom Reis kiko at async.com.br
Mon Dec 8 09:46:26 EST 2003


On Mon, Dec 08, 2003 at 09:34:05AM -0500, Shane Hathaway wrote:
> On Mon, 8 Dec 2003, Christian Robottom Reis wrote:
> > This is a tough problem. The nice thing about most SQL databases is that
> > when using a language binding you can just conjure a database connection
> > out of thin air with an address and a username. This is not so with the
> > ZEO.
> 
> This is because transactions are local to the SQL connections.  SQL
> connections are transactionally independent.  ZEO tries to be smarter than
> that, binding transactions to the thread instead of the database
> connection.  If you just made ZEO dumber by eliminating the
> get_transaction() global function, the deadlock issue would go away.  Or,
> more precisely, the responsibility for maintaining integrity across
> databases and connections would shift to application programmers.  I 
> wonder which is the better policy.

Well, being the implementor of setLocalTransaction gives you credentials
and perspective to evaluate this much better than I could hope to!

Having transactions bound to connections seems logical to me, but I'm
not a threads user, and nor do I advocate using them generally (yes,
of course they're appropriate in certain situations). It certainly is
more flexible, since having transactions bound to threads means you
can't do handle multiple transactions with a single thread, period; I'm
not sure if the ZEO is really being "smarter" there or just biased
towards a threaded approach <wink>.

However, we remain facing Dieter's original problem of having to shuffle
connections through his components because you can't fabricate
connections on-the-fly, and even if you did use threads you could very
well run into situations where two components were used part of the time
in separate threads, and part of the time in the same one.

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331



More information about the ZODB-Dev mailing list