On Thu, Feb 19, 2009 at 7:46 AM, Emmanuel Lecharny <elecharny@apache.org> wrote:

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.


ChangeLog.clear() should not remove entries from the backend.  It should only remove change events from the CL.
 

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

This makes sense but I don't know why you say "CL is not cleaned yet".  Looks like the clear(long) operation did clear out entries up to tag N.
 

Clear to tag N, step 2 : the CL is cleaned
server : E2 E3
CL : [tagN] add E1, mod E2, delete E3, add E4

This is exactly the same as the block above.  I don't understand what this "CL is cleaned is about"
 

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.

Recovery and consistency while managing these revert/clear operations are very important yes but I don't think they're relevant to the current conversation.  Right now all I want to do is come to some agreement on what the meaning and semantics are with the revert() and clear() operations and to discuss whether or not it's worth having a revertAndClear() composite function on the ChangeLog interface.

Do me a favor and clear your head and read my definitions without bringing in these ancillary conversations to this discussion.

    o ChangeLog.clear() and it's overload taking a long revision number clears out
       change events from the ChangeLog.  It has *NO* effect on the entries in the
       DIB (partitions of the server).
    o DirectoryService.revert() and it's overload taking a long revision number restores
       the state of the DIB to a previous revision while tacking on more change events
       into the ChangeLog in the process of restoring the state.

I think we're pretty much on base here but I may be misunderstanding what you mean by cleaned WRT the CL above.  Let me know if there are any differences in our thoughts.  Once we agree on this then I'd like to discuss why the revertAndClear() method is more appealing?  Then we can discuss the ancilliary topics like how do we properly conduct the revert operation with a live server to appear consistent to other clients during this process.  I have some ideas here but we can start another thread for it because this one has already gotten very long.

Thanks,
Alex