--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]>

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 :-)


Attachment: pgpFDifJT5DHg.pgp
Description: PGP signature

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to