directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: Some heads up about the Modify operation
Date Sun, 07 Nov 2010 16:08:30 GMT
On 11/6/10, Emmanuel Lecharny <> wrote:
> Hi,
> yesterday, (or was it the day before ?) we had an interesting chat with
> Stefan about the way the Modify operation is handled. Let me summarize
> what we said here.
> We discuss two aspects of the operation
> 1) Modification handling on the chain and in the backend
> Currently, we do the modification twice : one in a copied entry, and
> when done, we push the list of modifications (plus the operational
> attributes) to the backend, which grab the entry again and apply the
> modifications again too.
> We thing it's a waste of time. As the entry has already been modified in
> the schemaInterceptor, we should pass this entry to the backend, to push
> it in the master table in place of the old entry.
> One thing is needed though : as we may have to update indexes, we have
> to pass the original entry to the backend in order to do a diff to know
> which indexes have been modified.
hmm, I didn't understand why we need to do this 'diff to know which
indexes have been modified.'
> 2) Operation atomicity
> Right now, all the write operations are synchronized, so we have the
> guarantee that a modify operation will be done as an atomic operation.
> But it's not enough : another thread might have updated the entry before
> we enter into the backed.
> We think that we should use the entryCSN and modifyTimeStamp in order to
> check that it's not the case, when in the backend. If the entry TS/CSN
> has changed, then we should simply reject the operation.
> In order to do that, w will need to add a CSN/TS cache, which is not too
> complicated.
right, but I think having the CSN cache alone is enough
> That's all what we discussed, but they are very importants point that
> need some further discussion, and implementation, before 2.0.
> One last thing : I'm not sure we update the entryCSN when we modify an
> entry. That may be a problem when dealing with replication. Some insight
> is needed at this point.
we do update this, but done in DefaaultPartitionNexus, may be we
should move this to

thanks for sharing this interesting discussion

Kiran Ayyagari

View raw message