[ZODB-Dev] Items committed in one thread not seen inanotherthread?

[Tim Peters]

[Gwyn Evans]
>  Ah, now I see, thanks - I guess I was assuming there was a sort of
> 'push' from the transaction commit to the other threads, rather than the
> 'refresh' that's needed.

Right, and it's important to realize that this is how it must be, not that
it's just an arbitrary implementation choice.  A primary responsibility of a
transactional system is to give a _consistent_ view of the data.  If changes
from other threads "showed up" willy-nilly, whenever they were ready, the
thread processing the changes would see a haphazard mix of database states.

Instead each thread sees a point-in-time consistent view across all objects
it reads during a transaction.  In ZODB 3.2, that's enforced by raising
ReadConflictError if a thread even _tries_ to read an object for which
correctly consistent state is no longer available; in ZODB 3.3, by default
("Multiversion Concurrency Control", MVCC) a non-current (older) version of
an object's state is read up in such cases.

In either case, if you want to see current state, you need to cross a
transaction boundary.