directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: About the rename operation
Date Wed, 09 Jun 2010 09:30:33 GMT
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.


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.nextury.com



Mime
View raw message