--On 4. Mai 2007 21:22:49 +0200 Dieter Maurer <[EMAIL PROTECTED]> wrote:
Andreas Jung wrote at 2007-5-4 21:13 +0200:--On 4. Mai 2007 21:05:00 +0200 Dieter Maurer <[EMAIL PROTECTED]> wrote:But, the transactions are not concurrent in your original description! Instead, one transaction has been committed and (only!) then you see a transaction with the same id again.What are you trying to tell? The issue would also happen with a concurrent setup. That's why I presented a case where I would see the error in a non-concurrent environment. Got it?No. Not at all. Lets look at the subject which fortunately remained: You assume that some transaction objects are reused for subsequent requests. Transactions from subsequent requests are *NEVER* concurrent. Tim explained to you that it is natural that transactions in subsequent requests can easily have the same id. But, *CONCURRENT* transaction can *NEVER* have the same id. Thus, you can easily use your current caching algorithm: if you see the same transaction id, then either it is indeed the same transaction and you must associate the same connection or it is a different transaction. In this case, it is definitely nonconcurrent and can therefore, too, get the same connection.
As I said, I have a working solution meanwhile :-) Andreas
pgpFDifJT5DHg.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
