sang jun song wrote: > The changes in the Retro-Changelog (RCL) database are not guaranteed > to be in order > even in case of a single server, because the incoming requests are > processed > independently, and the scheduling of the worker threads ? that process > LDAP requests > ? is driven by the thread library. > There is a much higher risk for out-of-order changes in the RCL > database in case > replication is deployed (for reasons other than the above mentioned > thread scheduling > issue). > Invalid Changelog Entries > The contents of the RCL database cannot be fully trusted, because RCL > plugin > records the changes received by the directory server and not the > changes applied to > the database by the directory server. Typically, the URP code (update > reconciliation > protocol) may modify the received change and the RCL plugin may record > false > changes in the RCL database. > Is solved it? > There hasn't been any new work done in the retro changelog code for a long time so I suspect the answer is no. However, perhaps you could tell us more about your intended application using the rcl ? There may be a different way to achieve what you want to do. BTW, there _is_ now a mechanism to prevent out-of-order processing of updates inside a single server : it's used in replication sessions only at present but if someone had a strong motivation to ensure in-order processing they could make code changes to enable that existing mechanism.
