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.
>> And if you read carefully you see "provided their lifespans do not
>> overlap". Obviously, transactions with non overlapping lifespans are not
>The transactions were not overlapping. As Tim wrote: the transactions were
>distinct but they used the address.
Yes, therefore, you do not need to distinguish the two
transactions -- it is sufficient to distinguish the transaction ids.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org