You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/06/07 16:31:03 UTC
About the rename operation
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
- 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).
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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: About the rename operation
Posted by Alex Karasulu <ak...@apache.org>.
On Wed, Jun 9, 2010 at 12:30 PM, Emmanuel Lecharny <el...@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
Re: About the rename operation
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 6/9/10 10:52 AM, Alex Karasulu wrote:
> On Mon, Jun 7, 2010 at 5:31 PM, Emmanuel Lecharny<el...@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
Re: About the rename operation
Posted by Alex Karasulu <ak...@apache.org>.
On Mon, Jun 7, 2010 at 5:31 PM, Emmanuel Lecharny <el...@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?
> - 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.
> 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? Sorry I don't have the code right
in front of me but I trust that if you see this as a solution I am not
against changing the rename() method signature to fix this issue.
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?
Regards,
--
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