contextCSN of subordinate syncrepl DBs

[Rein Tollevik <rein@OpenLDAP.org>]

I've been trying to figure out why syncrepl used on a backend that is 
subordinate to a glue database with the syncprov overlay should save the 
contextCSN in the suffix of the glue database rather than the suffix of 
the backend where syncrepl is used.  But all I come up with are reasons 
why this should not be the case.  So, unless anyone can enlighten me as 
to what I'm missing, I suggest that this be changed.

The problem with the current design is that it makes it impossible to 
reliably replicate more than one subordinate db from the same remote 
server, as there are now race conditions where one of the subordinate 
backends could save an updated contextCSN value that is picked up by the 
other before it has finished its synchronization. An example of a 
configuration where more than one subordinate db replicated from the 
same server might be necessary is the central master described in my 
previous posting in 
http://www.openldap.org/lists/openldap-devel/200806/msg00041.html

My idea as to how this race condition could be verified was to add 
enough entries to one of the backends (while the consumer was stopped) 
to make it possible to restart the consumer after the first backend had 
saved the updated contextCSN but before the second has finished its 
synchronization.  But I was able to produce it by simply add or delete 
of an entry in one of the backends before starting the consumer.  Far to 
often was the backend without any changes able to pick up and save the 
updated contextCSN from the producer before syncrepl on the second 
backend fetched its initial value.  I.e it started with an updated 
contextCSN and didn't receive the changes that had taken place on the 
producer.  If syncrepl stored the values in the suffix of their own 
database then they wouldn't interfere with each other like this.

There is a similar problem in syncprov, as it must use the lowest 
contextCSN value (with a given sid) saved by the syncrepl backends 
configured within the subtree where syncprov is used.  But to do that it 
also needs to distinguish the contextCSN values of each syncrepl 
backend, which it can't do when they all save them in the glue suffix.
This also implies that syncprov must ignore contextCSN updates from 
syncrepl until all syncrepl backends has saved a value, and that 
syncprov on the provider must send newCookie sync info messages when it 
updates its contextCSN value when the changed entry isn't being 
replicated to a consumer.  I.e as outlined in the message referred to above.

Neither of these changes should interfere with ordinary multi-master 
configurations where syncrepl and syncprov are both use on the same 
(glue) database.

I'll volunteer to implement and test the necessary changes if this is 
the right solution.  But to know whether my analysis is correct or not I 
need feedback.  So, comments please?

--
Rein Tollevik
Basefarm AS