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 15:16:07 GMT
>> 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.
>> 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.

Ok, but then, as I said, we are injecting useless reverted operation
into the CL, as they will be removed when the clear() method will be
executed. If the clear() method is totally disconnected from the
revert() method, that's just find, but then I think there is some room
for a revertAndClear() method which combines both operations (remove
from backend and changelog) without doing useless operations (injected
reverted revert operation into the changelog).

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

Thi sis done in step 2, because if you do it in step 1, you can reach
an inconsistent state if the server crashes. In other words, if the CL
remains intact until the operations are reverted from the backend,
then you can use the CL to restore the backend if you have had some pb
during this first state.

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

This is the step 2 action : cleaning the CL is more appropriate.

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

This was my point : if we have to write a revertAndClean operation,
then we have to take care of the consistency. If we don't, and just
keep revert() and clean() as two separated methods, then that's
another story. The only thing that make me prefer a combined operation
is the useless injection of reverted revert operations into the CL
during the revert() operation.

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

Agreed (but it's not yet implemented).

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

No, i'm just a step forward : trying to write an efficient combinaison
of revert + clean without the superfluous CL addition done by the
revert() method. Otherwise, considering the semantic of revert() and
clean(), we are on base, since the beginning.

Once we agree on this then I'd like to discuss
> why the revertAndClear() method is more appealing?

let's start another thread for that. It will be more focused than the
stupid title we have (blah bla broken ?)

Emmanuel L├ęcharny

View raw message