[
https://issues.apache.org/jira/browse/DIRSERVER-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542106
]
Martin Alderson commented on DIRSERVER-1097:
--------------------------------------------
At the moment I am thinking that we would have an extra operation redundancy
table alongside the current replication logs which would have two columns, one
being the CSN of a new operation, the other being the CSN of an older operation
that is made redundant by the new one. This table would be generated on the
fly - i.e. when we add a new operation to the replication logs we also update
the redundancy table with any number of operations that are made redundant by
this.
I think the operations we can make redundant for each new operation would be
something like:
Operation | Operations to ignore
-----------------------+------------------------------
Add entry | None
Remove entry | All previous for this entry
Rename entry | None
Add attribute | None
Remove attribute | All previous for this attribute
Replace attribute | All previous for this attribute
Add attribute value | One previous matching remove attribute value and self
Remove attribute value | One previous matching add attribute value and self
I'm sure that formatting will come out well...
That table is just a quick draft which isn't quite right yet. It doesn't
really deal with matching up adds and removes.
I am not sure if this is the best design for this feature, nor am I sure how
this can fit in with the changelog service. I agree with you though that the
functionality of the replication service and the changelog service overlap a
fair bit and there probably should be some code sharing going on here.
> Only send net changes during replication
> ----------------------------------------
>
> Key: DIRSERVER-1097
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1097
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: mitosis
> Affects Versions: 1.5.1
> Reporter: Martin Alderson
> Priority: Minor
>
> During replication we currently send all changes that have occurred since the
> target replica was last brought up to date. We can optimise this by only
> sending the net changes. As an example, if an entry is created, modified
> several times then deleted at one server, we do not need to tell other
> replicas anything regarding this entry.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
