Mixing programmatic and declarative transactions in legacy software

Question

My question concerns about possible concurrency issues with mixing programmatic and declarative transactions. I am developing a legacy software (Spring + Hibernate) that handles database connections and transactions in a programmatic fashion.

Session db = HibernateUtil.getSessionFactory().openSession();
db.beginTransaction();
// do stuff
db.getTransaction().commit();

The software has newer modules that are using Spring data architecture with declarative transactions (@Transactional). We have experienced database deadlocks in rare cases with Microsoft SQL Server when newer Spring services are being called from inside "manually" opened transactions. I think the problem is that there are two nested transactions reading/writing same tables causing deadlocks.

Session db = HibernateUtil.getSessionFactory().openSession();
db.beginTransaction();
// do stuff
springService.getStuff();
// do stuff
db.getTransaction().commit();

Is there a way to mix these transactions safely or use the already started transaction in both? Should I just close the manually/programmatically opened transaction before calling Spring @Service/@Repository methods? Both Spring and HibernateUtil uses the same entity manager for database connections.

Answer 1

When it comes to the behavior of the transactions, there is really no difference between declarative and programmatic/manual ones. Declarative transactions enable you to demarcate transaction boundaries in a more concise and readable way, that's all about it. Under the hood, Spring will do the same thing you would do manually to start and commit/rollback transactions.

I think the problem is that there are two nested transactions reading/writing same tables causing deadlocks.

Very possible.

Is there a way to mix these transactions safely or use the already started transaction in both?

Whether it is safe to do it in your specific part code highly depends on what the code does. If a nested transaction will cause deadlock, then it's obviously not safe, and that has nothing to do how you obtained the nested transaction (manually or Spring started it when intercepting a method annotated with @Transactional(propagation = Propagation.PROPAGATION_REQUIRES_NEW)).

Should I just close the manually/programmatically opened transaction before calling Spring @Service/@Repository methods?

Again, depends of what you need to solve. If you need the outer transaction to proceed once the nested transaction completes, then you shouldn't. Otherwise you can.

TransactionTemplate is the recommended way to manually start transactions with Spring, because Spring is then aware of transaction boundaries, meaning it will treat such a transaction the same as if it were started declaratively with a Spring annotation.