directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: ChangeLog + revert, broken , take 2
Date Thu, 19 Feb 2009 12:46:16 GMT

>> 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 

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

View raw message