directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: About the rename operation
Date Wed, 09 Jun 2010 09:47:33 GMT
On Wed, Jun 9, 2010 at 12:30 PM, Emmanuel Lecharny <elecharny@gmail.com>wrote:

> On 6/9/10 10:52 AM, Alex Karasulu wrote:
>
>> On Mon, Jun 7, 2010 at 5:31 PM, Emmanuel Lecharny<elecharny@gmail.com
>> >wrote:
>>
>>
>>
>>> Hi guys,
>>>
>>> I have an issue with this operation. The way it works is currently :
>>> 1) grab the old entry from the backend immediately (eagerlyPopulateFields
>>> in InterceptorChain).
>>>
>>> This is done to spare lookups all aver the following interceptors
>>>
>>> 2) as we go down the chain, do a lots of checks and update, including
>>> adding the missing operational attributes (lastModifier, lastModifyDate),
>>> and if needed, delete the old RDN from the entry
>>>
>>> 3) in the backend, call the store.rename() operation which takes 3
>>> parameters :
>>> - DN (the entry DN)
>>> - new RDN (the new name)
>>> - deleteOldRdn flag
>>>
>>>
>>> Here, I think we have a double problem :
>>> - first we have grabbed the entry just for the purpose of doing some
>>> checks, assuming that we will grab it again in the store
>>>
>>>
>>>
>> Have you confirmed that we in fact grab the entry once again a second time
>> in the store?
>>
>>
> Yes, and it has been fixed since then.
>
>
>>
>>
>>> - second, we will have to call the modify() operation after the rename
>>> has
>>> been done, as we have lost the Operationnal attribute update, so the full
>>> operation has a double cost (maybe more).
>>>
>>>
>>>
>>>
>> Correct! This is a big issue that may compromise atomicity.
>>
>>
> And has been fixed.
>
>
>>
>>
>>> I suggest that we modify the rename() parameters to pass the modified
>>> entry
>>> instead of doing the modification into the store, because, anyway this is
>>> not where the logic should be placed.
>>>
>>> wdyt ?
>>>
>>>
>>>
>>>
>> Does your analysis show that the two main problems above (atomicity and
>> unnecessary entry lookup) are eradicated?
>>
> They are.
>
>  However the issue of loosing atomicity due to operational attribute
>> updates
>> is a problem that exists for all write operation minus the add operation.
>> If
>> this alteration fixes the problem for rename, will the same tactic fix
>> issues with other write operations minus add WRT to the operational
>> attribute atomicity problem?
>>
>>
> They will. I'm working on it. Currently fixing the Move operation.


Excellent. Great job Emm.


-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Mime
View raw message