Re: [infinispan-dev] exceptions and locking policy
On 6 Sep 2010, at 10:52, Mircea Markus wrote:
Hi,
This is about what happens with locking and transactions when an exception appears during
an invocation. It might be a e.g. TimeoutException or an CacheStore related exception or
any type of exception.
Deadlock detection code relies on this policy, so I need to clearly define it.
Current logic is rather unclear and spreads over multiple interceptors:
- CallInterceptor would mark the tx for rollback if ant exception happen. This won't
include TE as lock acquisition happen earlier in the call stack
^^ What's TE? TimeoutException?
- InvocationContextInterceptor releases locks on all keys associated
with this call, but doesn't care if the call is in a tx or not so it doesn't
rollback tx or release tx locks (this logic rather belongs in LockingInterceptor)
It would release tx locks specific to the invocation. Look at the impl of the
InvocationContext used to retrieve the locks in question.
Granted, it doesn't cause the transaction to roll back though - and IMO it should. Do
you have a list of exceptional conditions which do not cause a transaction to roll back at
the moment? I suppose cache store exceptions?
- TxInterceptor and LockInterceptor just ignore exceptions
You mean, pass them up higher in the interceptor chain - possibly for the
InvocationContextInterceptor to deal with.
As discussed in a previous email, the desired behaviour in case of a
TimeoutException is to mark the tx for rollback. I think this can be extended as a rule
for any type of Exception happening during a transaction - e.g. store exception, remote
communication exception etc. On the short, if the user receives any kind of exception
while writing in a tx (e.g. cache.put() throws an exception) he should know that tx was
marked as rollback only. Wdyt?
Yep. And the InvocationContextInterceptor is the best place to trap this and deal with it
since it will have visibility of exceptions further down the chain (provided they
aren't swallowed somewhere). Essentially the stuff that the CallInterceptor does when
it catches an exception in command.perform() should be moved to the
InvocationContextInterceptor.
http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
Naturally we should (a) list all exception types we can come up with, in each interceptor
(b) test behaviour on an ongoing transaction for each of these exceptional types. A
single functional test should do the trick.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
Attachments:
- attachment.html (text/html — 5.0 KB)