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
- 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)
- TxInterceptor and LockInterceptor just ignore exceptions
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?
Cheers,
Mircea