directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@gmail.com>
Subject Re: ChangeLog + revert, broken , take 2
Date Thu, 19 Feb 2009 14:47:46 GMT
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

Mime
View raw message