[infinispan-dev] [ISPN-548] Discussion on updating the QueryInterceptor to be able to update old keys

[Emmanuel Bernard]

On 21 juil. 2010, at 14:36, Navin Surtani wrote:

>> Make a UPDATE work on index, is not the same thing to do steps 2, 3 and
>> 4? Or UPDATE is computationally more expensive? Or there is another
>> reason to avoid the UPDATE?
> 
> Not really as far as I know. Emmanuel would know this answer better. I 
> just wanted to have clarity from the other guys on the list before I 
> went in and made the change.

UPDATE is really DELETE+INSERT
DELETE performs a query + marks the element as deleted

If we can avoid it by knowing that the key was already present the better.

I'm concerned about your description of #2
"2 - Interceptor checks the set of keys used within the same context to see if the same key has been used"
WDYM by same context? same tx? if someones has a detached version of the entity from another tx, he can reattach it on the same key and this has to be picked up as an UPDATE.

So it all depends if the index is stored locally or not. and whether the key lookup requires a network roundtrip or not. I suspect the decision matrix is something like that:

                         |  Key lookup local | Key lookup remote
--------------------------------------------------------------------
Index local     |  do lookup              | do UPDATE
Index remote | do lookup               | do lookup