[
https://issues.apache.org/jira/browse/DIRSERVER-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny reopened DIRSERVER-840:
-----------------------------------------
I reopen the issue, because the double modification _is_ necessary. The 'fix'
had a very bad side effect, which was not exhibited because the way the
operational attributes were added to the list of modified attributes was
incorrect : the list was never modifed in fact...
Here is the reason why we need this double modification :
- the opAttr interceptor first call the schema interceptor
- the schema interceptor check for every modification, and if the modified attr
is not modifable by user (and this is the case for modifiersName and
modifyTimestamp), it generates an error
- as the opAttr interceptor was not correctly injecting those two attrs into
the modification list, it worked well, except that we lost those modifications
- and at the end, the second modification was here to store those operational
attribute directly into the nexus.
What was bad about this double modification (and still is) is that we cannot
guarantee that the operation is atomic( we have 2 mods in a row for the same
entry). Even from the perf perspective, it's far from being perect.
Now the problem is that we have no easy way to add the 2 opAttrs before calling
the schema interceptor, because those attrs will be seen as invalid, and it
will generate an error.
One possible solution would be to add a flag in the ModificationItem structure
to signal an attribute which has been added by the server.
> Double modification on a modify ?
> ---------------------------------
>
> Key: DIRSERVER-840
> URL: https://issues.apache.org/jira/browse/DIRSERVER-840
> Project: Directory ApacheDS
> Issue Type: Improvement
> Reporter: Emmanuel Lecharny
> Assignee: Alex Karasulu
> Fix For: 1.5.1
>
>
> We have had a convo with alex about the OperationalService. I saw that when
> doing a modification on an entry, we first call the next interceptor (and
> this will modify the entry on the backend), then we add two new attributes
> (modifiers name and date) and store again the data into the backend. This
> does not seems to be very efficient, but we don't remember the reason why
> it's done like that ...
> Here is the convo
> elecharny in OperationalService
> akarasulu yep
> elecharny when doing a modify,
> akarasulu ahha
> elecharny you first call the next interceptor, then you update the nexus with
> the entry with
> elecharny two new attributes
> elecharny why don't you add the attrs into the entry and then call the netx
> interceptors ?
> akarasulu hmmm I had some reason for this
> elecharny this is a simple modify instead of two
> akarasulu don't remember
> akarasulu yeah yeah I see what you mean
> akarasulu can't remember now
> elecharny this seems to cost the double
> akarasulu yes it does
> akarasulu can you put this in JIRA
> elecharny yeah
> akarasulu just past this info
> akarasulu from IRC
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
