On Wed, Jun 9, 2010 at 12:30 PM, Emmanuel Lecharny <firstname.lastname@example.org>
Yes, and it has been fixed since then.
On 6/9/10 10:52 AM, Alex Karasulu wrote:
On Mon, Jun 7, 2010 at 5:31 PM, Emmanuel Lecharny<email@example.com>wrote:
Have you confirmed that we in fact grab the entry once again a second time
I have an issue with this operation. The way it works is currently :
1) grab the old entry from the backend immediately (eagerlyPopulateFields
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
- 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
in the store?
And has been fixed.
- second, we will have to call the modify() operation after the rename has
Correct! This is a big issue that may compromise atomicity.
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
Does your analysis show that the two main problems above (atomicity and
instead of doing the modification into the store, because, anyway this is
not where the logic should be placed.
unnecessary entry lookup) are eradicated?
They will. I'm working on it. Currently fixing the Move operation.
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?
Excellent. Great job Emm.