Some heads up about the Modify operation

[Emmanuel Lecharny <el...@gmail.com>]

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

Re: Some heads up about the Modify operation

[Emmanuel Lecharny <el...@gmail.com>]

On 11/7/10 5:08 PM, Kiran Ayyagari wrote:
> On 11/6/10, Emmanuel Lecharny<el...@gmail.com>  wrote:
>> 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.'

Because some AT may have been added, some others may have been removed, 
and some values can have been added or removed, all for indexed ATs. We 
have no way to know which ATs have been impacted, and in which way, 
without buildling a diff.

We can't use the Mods, because we may have operations impacting the 
final index more than once, so better comparing the end results to the 
original one with a diff.

>> 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

Probably. I may have overlooked the need to use the TS, true.

>> 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
> OperationAttributeInterceptor
Yeah, that would be probably better.

Thanks for the comments, Kiran.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Some heads up about the Modify operation

[Kiran Ayyagari <ka...@apache.org>]

On 11/6/10, Emmanuel Lecharny <el...@gmail.com> 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.
>
+1
> 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
OperationAttributeInterceptor

thanks for sharing this interesting discussion

-- 
Kiran Ayyagari