You can do a revert(int a) followed by a clear(int a) to bring the server
back to state 'a' and remove any record of changes in the changelog.
Better do a clear(). Unless the clear() just remove info from the
changeLog. In my mind, clear = remove from server and changelog.
clear() is a method that we're considering putting into the ChangeLog
interface. So it will not remove anything from the DIT but should remove
change events from within the ChangeLog.
So let me sumarize :
- revert() will remove entries from the backend, but will add the
reverted operation into the changelog
- clear() will remove everything from the changelog up to a specific rev
or tag, but don't remove anything from the server
That mean we need to do a revert() followed by a clear() to remove
entries from the backend and from the changelog, assuming that in this
case, we will have added reverted operation into the changeLog for nothing.
In this case, a revertAndClear() operation which removes entries from
the server and remove the associated reverted operations from the
changelog, in order to avoid this useless reverted operation creation
and storage. We can live with it, but as this is the second iteration on
ChangeLog, it may be time to give it a second thought.
So the clear() semantic is : remove everything from server and
changelog
Just from the changelog.
Doing so mean that you store reverted operation of the revert
operation which will be removed by the subsequent clear(). A bit
useless...
I don't think so. You need to log all changes otherwise you'll have
anamolies and will realize later that certain things will not be possible.
The clear() operation I have in mind will remove entries from backend
one by one. When done, the CL can be cleaned. There is no way we can
remain in an inconsistent state (assuming you don't have pb between
those two steps, of course !). I don't see what kind of anomaly we can
face.
Let me explain a bit further why I think it can be just ok. Suppose you
start to remove everything from the backend, not logging the associated
reverted operation in the changelog, and that the server crash in the
middle. Here is the server's state in this case :
Before tag N :
Server : E2 E3
Operations after tag N
CL : [tagN] add E1, mod E2, delete E3, add E4
Server : E1 E'2 E4
Revert to tag N
CL : [tagN] add E1, mod E2, delete E3, add E4, del E4, add E3, mod E2,
del E1
Server : E2 E3
Clear to tag N, step 1 : the CL is not cleaned yet
server : E2 E3
CL : [tagN] add E1, mod E2, delete E3, add E4
Clear to tag N, step 2 : the CL is cleaned
server : E2 E3
CL : [tagN] add E1, mod E2, delete E3, add E4
If the server crash between step 1 and step 2, we just have to clean the
CL. If the server crash somewhere during step 1, if we have keep the
current CL reverted operation being executed before the crash, we can
restart from this point. If the server crash during step 2, we just have
to clean the CL, assuming we know that we were executing step 2.
In no case we can loose information.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
