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.
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.
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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
