[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