[ZODB-Dev] How to update an object in a multithreading application?
Vincent Pelletier
plr.vincent at gmail.com
Tue Mar 20 08:25:44 UTC 2012
Le lundi 19 mars 2012 21:49:11, Jim Fulton a écrit :
> sync should be deprecated. :)
>
> transaction.begin() is better.
Off-topic: it is possible that calling transaction.begin() does not offer a
most up-to-date view of the database.
This is easy to notice when using another database concurrently (ex: MySQL)
with (implicit) referential integrity constraints, and with several clients
for the same ZODB (ex: ZEO):
- Transaction 1 alters a persistent object and, say, inserts a line in a
table.
- Transaction 1 commits: ZEO sends invalidations to other clients, MySQL makes
the new row visible to any new transaction.
- Transaction 2 starts: for some reason, it doesn't pick up the invalidation
(nothing in the code guarantee that it picks it up), so it sees the object
before the modification. Still the row is visible in MySQL.
My point is that ZODB should try harder - or provide a way for its backend to
try harder - to see the most up-to-date database state possible. In the case
of ZEO, this means doing a network round-trip from client to ZEO: when the
round-trip is over, any packet sent by ZEO up to "pong"-ish will have been
received and handled by client.
I do understand that there is anyway a chance for such event occurring even
when such round-trip occurs (because of multi-database transactions, or
actually multi-transactional-connection transactions), but in practice
applying what I described above and using sortKey() API is enough to solve the
issue wherever inter-database dependencies are one-way.
--
Vincent Pelletier
More information about the ZODB-Dev
mailing list