[ZODB-Dev] How can reading trigger a ConflictError?

[Toby Dickenson]

On Thu, 26 Apr 2001 11:59:12 -0400, gward@mems-exchange.org wrote:

>So why does it work like this?  I thought the whole point of =
transactions
>was to isolate concurrent processes from each other; shouldn't process B
>happily see the "old" picture of the database until it does something to
>resync (eg. commit or abort a transaction),

It will either see it happily, or raise a ConflictError.

> at which point it sees the "new"
>picture as committed by A?  Or is this a naive understanding of
>transactions?  Or do I just not understand ZODB/ZEO's transaction model?
>(Is it documented anywhere yet?)

Yes, I too was suprised by this behaviour but it is exactly as you
describe.

ConflictErrors only happen when loading an object into memory (or
comitting, obviously), so it is possible to minimise wasted effort by
touching likely-to-be-modified objects early in the transaction.

Alternatively you can perform the read-only transaction in a unique
'Version', but this incurs an additional overhead.


Ive thought for a while that it may be possible to (ab)use some of the
Version machinery to provide a transaction with the semantics expected
by Greg, with less overhead than a full Version. Unfortunately it is
way down my todo list.


Toby Dickenson
tdickenson@geminidataloggers.com