How to restart transactions on deadlock/lock-timeout in Spring?

Question

Hi,

What is the best practice on implementing a transaction restart upon deadlock or lock timeout exceptions when using Spring (specifically the Spring recommended approach: declarative transactions) ?

Thanks,

Asaf

Answer 1

There is no universal answer because it depends on application specifics. For example you may want to perform automatic transacted operation restart or notify the user about operation failure and ask for explicit retry confirmation etc.

I'd use AOP in case of automatic restart scenario.

Answer 2

I feel like Spring itself should have a good answer to this question (in the form of documentation, at the least, or a retry interceptor of some sort). Alas, it does not.

Probably the best way to handle retries (if you want to continue being "declarative" about things) is to write your own interceptor implementation that will automatically retry the transaction a configured number of times. For starters, study Spring's TransactionInterceptor, which manages begin/rollback/commit behavior for declarative transactions. If you're using Hibernate, note how it handles Hibernate session binding/unbinding to the current Thread.

Things to watch out for if you're using Hibernate:

• Your "retry interceptor" should be sure to unbind any preexisting thread-bound Hibernate session and rebind a new one. Once an exception (e.g., deadlock) is thrown from within Hibernate/JDBC code the corresponding Hibernate session is poisoned and needs to be discarded. (session.clear() is not sufficient.)
• Be careful if your transactional service methods use Hibernate session objects as method parameters. On retry, when you reset your Hibernate session, these objects will be detached. You'll need to reattach them if the service method assumes they are attached (e.g., if they use lazy loaded properties that get accessed in the service method, or if you try to save them, etc.) In general, it's better if you don't use Hibernate objects as parameters to transactional service methods.
• You'll be implementing MethodInterceptor.invoke() -- the MethodInvocation instance that gets passed in to this may be stateful; you may need to clone it before using it in the interceptor.