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

[Mircea Markus]

On 21 Jul 2010, at 13:58, Emmanuel Bernard wrote:

> 
> 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.
If the discussion is about InvocationContext, which is passed to the QueryInterceptor's method, then it means the transaction's context (assuming the call is made in a tx's scope): it holds reference to all the locks acquired by the given transaction, all the keys "touched" etc.
> 
> 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
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev