On 6 Sep 2010, at 11:10, Manik Surtani wrote:


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?
yes

- 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?
The ones I can think of are:
- timeout exceptions (local or remote)
- cache store exceptions
- deadlock exceptions
- replication/invalidation exceptions
- exceptions from custom interceptors.
- InvalidStateException if if call is made in the scope of a transaction that was marked for rollback

- TxInterceptor and LockInterceptor just ignore exceptions

You mean, pass them up higher in the interceptor chain - possibly for the InvocationContextInterceptor to deal with.
yes

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/infinispan/interceptors/CallInterceptor.java?r=604#l74
I agree that is the best solution. The drawback is the fact that we would have the locking logic spread over two interceptors instead of one - LockinInterceptor(harder to follow etc). Same with tx. These would need to be well documented.  

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.
Sounds good. Any other exceptions you might have in mind?
I've also renamed ISPN-629 to cover all exceptions (not only TE).

Cheers
Manik
--
Manik Surtani
Lead, Infinispan
Lead, JBoss Cache




_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev