directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Some heads up about the Modify operation
Date Sat, 06 Nov 2010 12:57:41 GMT

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.

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 

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.

Emmanuel L├ęcharny

View raw message