Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 74.125.82.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=JqTqnhhd4YDdEgJqzsFJMEGVT1w1dwbEGbmo/VAmGdtfSbIu4HlhpQ4Fn3N6sLY3wV
         eQrhLTWX8X6ragzdwCj+ztgyAH67rYH5rFZbe3KttPAhmfh4YjBEJT0lq6fMExcp7wv9
         6uXZii+RjTZyrI+lbtIZ5uDOgRkaqtbN2w8pU=
Message-ID: <4C0F5F39.4090301@gmail.com>
Date: Wed, 09 Jun 2010 11:30:33 +0200
From: Emmanuel Lecharny <elecharny@gmail.com>
Reply-To: elecharny@apache.org
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: About the rename operation
References: <4C0D02A7.7090905@gmail.com>
 <AANLkTin9I_JbpDGRZNYjmJsgEGOlnU_mTjCDmDZon6VG@mail.gmail.com>
In-Reply-To: <AANLkTin9I_JbpDGRZNYjmJsgEGOlnU_mTjCDmDZon6VG@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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