Re: syncrepl overlay

[Howard Chu <hyc@symas.com>]

OK, so aliases aren't a problem - the issue I see now is a lack of 
transaction protection when moving the code out to an overlay. For 
persistent search, the changes may get sent to consumers in different 
order, and for multiple modification events on a single entry the 
updated entry may not correspond to the op csn.

For example, to process a modify:
 1) There is a pre-modify test to see if the target entry currently 
satisfies a Psearch.
 2) Then the modify occurs.
 3) Then there is another test to see if the target still satisfies any 
Psearch.

For a given Psearch:
   if (1) is TRUE
      if (3) is TRUE
         send an UPDATE message
      else
         send a DELETE message (target has left the scope)
   else
      if (3) is TRUE
         send an ADD message (target has entered the scope)

If two modifies are (near) simultaneously directed at the same entry, 
then these three steps can get interleaved. If each Modify is 
represented as two boolean states (results of step 1 and step 3) then 
for two simultaneous Modifies there are 16 cases.

     00  01  10  11
 00  OK  AA  OK  --
 01  AA  --  ?D  AU
 10  OK  UA  --  DD
 11  --  AU  DD  OK

Four of these are impossible, will never occur. Four of these are OK, 
the correct result will occur regardless. In the other eight cases, 
anomalies may occur:
  01x00 or 00x01 - the target is out of scope, one modify leaves it out 
of scope, the other makes it enter scope. Only one Add message should be 
generated, but it's possible for two to occur instead.
  01x11 or 11x01 - the target is out of scope, one modify makes it 
enter scope and the other leaves it in scope. One Add and one Update 
message should be generated. It's possible for the Update to be sent 
before the Add message.
  11x10 or 10x11 - the target is in scope, one modify leaves it in 
scope, and the other takes it out of scope. One Update and one Delete 
message should be generated, but it's possible for two Deletes to be 
sent instead.
  01x10 - the target is out of scope, one modify puts it in scope, the 
other takes it out of scope. One Add and one Delete should be generated, 
but it's possible that only the Delete will get sent.
  10x01 - the target is in scope, one modify takes it out of scope and 
the other puts it in. One Delete and one Add should be generated, but 
it's possible that an Update and an Add will be sent instead.

Ultimately I guess if the consumer is flexible enough, it's not a major 
tragedy because it doesn't look like any actual data loss occurs. ???

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support