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.