Re: [infinispan-dev] [ISPN-548] Discussion on updating the QueryInterceptor to be able to update old keys
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev