On 7 Jul 2010, at 23:20, Sanne Grinovero wrote:
Hello,
I was quite surprised to hit a timeout on lock acquire on a method
flagged with SKIP_LOCKING.
This is almost certainly a bug.
Debugging I've found that in case a batch operation is running
and no
transaction is active org.infinispan.interceptors.BatchingInterceptor
creates a new InvocationContext, ignoring the existing one, and so the
invocation proceeds but the flags I defined are cleared.
Hmm, it should only create a new InvocationContext if there *is* an active transaction
(not if there is *not* one). This is because batching is implemented using transactions,
and to prevent interference with an existing transaction, a new context is used to isolate
the batch from the tx.
What is the reason to create a new InvocationContext? Could that be
changed to at least carry over the defined flags?
Carrying over flags is the generic fix, since it covers both the case of a tx being
present and not. So this should be done anyway, but we should also look at why a new
context is created if there is no ongoing tx.
I've been playing with it by using setFlags(existingFlags) and
have
already experienced another little performance boost with Lucene,
especially as it's now respecting SKIP_REMOTE_LOOKUP too, but I'm not
going to change this without understanding.
Go ahead and fix by carrying over flags. Like I said this should have happened anyway.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org