[ZODB-Dev] Same transaction object (re)-used for subsequent requests?

[Dieter Maurer]

Andreas Jung wrote at 2007-5-4 21:13 +0200:
>
>
>--On 4. Mai 2007 21:05:00 +0200 Dieter Maurer <dieter at handshake.de> 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
>> concurrent...
>
>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.



-- 
Dieter