[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