views:

122

answers:

2

There have been various posts of logging the activity (start, commit & rollback) of Spring's transaction manager. However, I recently came across a deadlock issue for which logging just the activity isn't enough.

The fundamental issue in our code is a messy usage of transaction propagations REQUIRED and REQUIRES_NEW. There are so many method calls back- and forth that we end up with a lot of transactions stacked onto each other. Alas, the code base is huge and the solution urgent... (We all know what this is.)

The issue was a deadlock because code was added to query entities in a transaction that were sub-sequentially modified in another transaction. Spring spits out an exception telling the update of entity X times out because it's locked. Now, Knowing this is nice, but how does one find the faulty code: The query which does the early locking.

My question (at last) : Is there a way to log the entities being added to a transaction ? This way I can specifically look for transactions locking the entity Spring is complaining about.

Thanks ! :-)

A: 

Try to log queries in your ORM. May be it will be easier way to find "bad" transaction.

Donz
+1  A: 

Spring delegates to a transaction manager, so Spring doesn't know what entities are touched in the transaction, the transaction manager does. As Donz said, looking at the transaction manager for information is the best investigative approach.

You could also go over all transaction definitions and remove REQUIRES_NEW from everything except write only/write always type methods (like auditing or logging). If you have REQUIRES_NEW in your main business logic it is a bug or some very odd design. Blindly removing it might have less side effects than you think.

iwein