[Neo-report] [Bug #1165] Implémenter le controle des messages d'invalidation
Vincent Pelletier
vincent at nexedi.com
Wed Jun 24 11:13:19 CEST 2009
Bug : Implémenter le controle des messages d'invalidation
Status : Open
Date : 2009/06/23
Link : http://erp5.nexedi.com/bug_module/1165/view
Reporter : Aurelien Calonne
Supervisor : Vincent Pelletier
Request Project : NEO R&D
Assigned Project : NEO R&D
Description:
Voir titre et vincent pour plus de détails
Messages :
++++++ Message #2 submitted by Vincent Pelletier on 2009/06/24 11:13:18 GMT+2 ++++++
Presentation of the problem:
What is needed:
- any networked zope storage
- 2 client nodes
Scenario:
- node 1 modifies object A and commits
- storage sends invalidation messages to all nodes
- node 2 reads object A before it had a chance to process the invalidation message (net lag, python threading unresponsiveness for the thread handling invalidations, whatever) and gets outdated data
Symptoms:
- unable to find a subobject of A (if the modification to A was adding a subobject)
- propagating to another object outdated values, making transaction serialization impossible (the transaction on node 2 might be triggered by transaction on node 1, still it sees data from before transaction 1)
Solution for Neo:
Basicaly, we must make sure that a transaction was started with the latest invalidation message already processed.
Implementation design is a difficult part.
A solution would be to make TPC vote detectthis and fail, but the difficult part if to identify the invalidation message which has been sent prior to zope transaction begin (*not* TPC begin).
Another solution would be to have an exchange between CN and PMN to make sure pending invalidations are effectively processed, but it will induce connection lag in transaction begin.
++++++ Message #1 submitted by Aurelien Calonne on 2009/06/23 09:48:29 GMT+2 ++++++
More information about the Neo-report
mailing list