Thanks for the responses, all.
Apologies for the delay in getting back to you - having a family problem
at the moment so have very little spare time.
I thought having the replication logs stored in LDAP sounded nice - for
new replicas we have to send all replicatable entries but after that the
log LDAP entries can be sent instead. It would be pretty much the same
code logic and it just seemed to solve all the problems with a large
amount of code re-use. I was worried about possible performance hits
though and it sounds like you (Alex) don't want to store the logs in
LDAP for the same reason.
My main reasons for suggesting storing the logs in LDAP are:
1. So we can have optional attributes in each log entry. This is needed
when we "explode" the current message blob so it can be queried
efficiently. With JDBM I guess we would have to specify a new table for
each type of message.
2. To reduce the code complexity. We would have virtually the same code
for sending whole entries as sending the logs and we would have less
code for dealing with the data storage in general.
3. To reduce the current tight coupling with the backend database. By
using LDAP as the abstraction layer we could leverage ApacheDS' existing
mechanism for specifying the data store.
4. To allow an easy way to view the logs.
5. It seems to be the most natural fit. Since we need to store (part
of) an LDAP entry in the logs, why not store it in LDAP?
I'll take another stab at explaining that: we already have code to store
LDAP entries in a database, so why would we want to write that again?
Yeah, we have a JIRA about this:
> Oh this reminds me that we also need to make sure we're generating
> UUIDs all the time even if replication is not enabled.
Resuscitating a deleted entry seems like something most people wouldn't
> For example you have a delete of a node occur right when you add a
> child to it. The server would probably put the child into some
> lost and found area and alert the administrator. With tombstoning
> you can easily resuscitate the deleted parent and move the child
> back under it.
If we are attempting to simulate a single server as much as
possible (which is my main aim)
then the new child entry should be
deleted when the peers synchronise. As you said, we could have an
optional lost and found area for cases where conflict resolution causes
data loss like this, along with optional notifications to an administrator.
>> Also our MMR support is still immature, we don't yet do value-level
>> conflict resolution.> Yeash we have yet to consider that.We will have this once I have fixed