My thoughts about Spring Transactions

I've some thoughts about spring (and spring-boot) transactions I want to list somewhere, and I think here's a nice place.

Preface

Spring do transaction management through PlatformTransactionManager interface.

This interface has implementation for different kinds of datasources, for example for DataSourceTransactionManager, HibernateTransactionManager, HibernateTransactionManager, JmsTransactionManager, JpaTransactionManager and others.

In a typical JPA application, the JpaTransactionManager is being used.

In SpringBoot, All the JpaRepository are annotated with @Transactional annotation.

This annotation used by spring to do the Declarative transaction management.

So, the Developer uses this annotation to control many things, included the transaction propagation (REQUIRED, REQUIRED_NEW, SUPPORTED, etc), the isolation level (READ_COMMITED, READ_UNCOMMITED, etc.) and the rollback exception, timeout and more.

And behind the since, the platform-specific transaction manager along with the databasource do the actual work.

@Transactionl

So, many people says, use the @Transactional annotation on the service layer, you might need to use it on DAO (now called Repository) layer, but do not use it on the controller layer.

In spring boot, as I said, all the out-of-the-box methods that you get by implementing the JpaRepository are already have the @Transactional annotation (see SimpleJpaRepository). And I think hence the @Transactional on the implementation class itself, then all your repo methods might have the annotation as well.

But this is not the problem, the problem in the Service layer.

@Transactionl in the Service layer

What if I didn't put the Transactional annotation on my service methods?
Then your method will not run in a transaction, so If you have a service method that do the following

public void serviceMethod(){
     insert1();
     insert2();
}

insert1() might succeed and inserts data into the database, while insert2() fails.

In this case you should put the @Transactional annotation on your service method if you want to have all or none.

@Transactionl and noRollbackFor

The rollback is controlled by RuleBasedTransactionAttribute
see http://docs.spring.io/autorepo/docs/spring/current/spring-framework-reference/html/transaction.html#transaction-declarative-rolling-back

In its default configuration, the Spring Framework’s transaction infrastructure code only marks a transaction for rollback in the case of runtime, unchecked exceptions; that is, when the thrown exception is an instance or subclass of RuntimeException. ( Errors will also - by default - result in a rollback). Checked exceptions that are thrown from a transactional method do not result in rollback in the default configuration.

Also,

When the Spring Framework’s transaction infrastructure catches an exception and is consults configured rollback rules to determine whether to mark the transaction for rollback, the strongest matching rule wins 

For rollbackFor and noRollbackFor;

I think spring take the exception thrown and check to see how it is close (in inheritance hierarchy) to the declared exceptions (in rollbackFor and noRollbackFor). If it is closer to an exception declared in rollbackFor more than one declared in noRollbackFor, then the transaction will be rollbacked. and vice versa.

ex:
We have this heirarcy:
class Exception1{}
class Exception2 extends 1{}
class Exception3 extends 2{}

@Transactional(rollbackFor=Exception1.class, noRollbackFor=Exception2 .class)
public void myMethod(){
        throw new Exception3 ();
}

In this case, the transaction will NOT be rollbacked, because the thrown exception (Exception3) is closest to exception in noRollbackFor (Exception2) than the exception in rollbackFor (Exception1)

And if the closest exception declared in rollbackFor, the spring will rollback the tx, otherwise it will not rollback it:

in RuleBasedTransactionAttribute: return !(winner instanceof NoRollbackRuleAttribute);

@Transactionl and lazy evaluation

lazy evaluation is important aspect in web development, it facilities things, lazy evaluation includes not only evaluate lazy associations in the Controller layer, but also evaluation lazy Streams. (Thanks to OpenEntityManagerInViewFilter).

But if you choose to annotate your service method with @Transactional, lazy transaction data will not be available in the Controller layer (and exceptions will be thrown as well).

Here's an example issue.

So, some people says, at service layer get all the data you want and then send it to the controller layer as eager so you don't need the service layer's transaction anymore.

I think for finder services, you might not need to have the @Transactional annotation, so you can make use of the OpenEntityManagerInViewFilter (which is provided by springboot by default) and be able to  enjoy your laziness in the controller layer.(It seems the "Open EntityManager in View" has nothing to do here, it only allow the transaction manager to use an EntityManager created by him. because if you have @Transactional and have this pattern on, the exception will continue to throw if you try to access lazy data out of the transactions.

But in case of services that updates the database, you do need to use the @Transactional annotation to control the things not to go messy!

@Transactionl on controller and service layer

If you have a finder method that returns a lazy object (java 8 stream or lazy association as in hibernate), the if you have the @Transactional annotation on the service layer, then the lazy parts of  object will not be available to the controller layer.

However, if you put the @Transactionl annotation on the controller layer as well (which many people don't recommend) then the lazy part will be available to the controller layer unless you make the transaction propagation on the service layer as REQUIRED_NEW, in this case the service layer will suspend the controller's transaction and start/end it's own transaction and will send back the object to the controller out of its transaction and the problem will still exists.

Conclusion

For now, I'll  - mostly, because some times I do not need it - use @Transactionl on Service methods that do update (Add/update/delete) the database.

However for finder service methods (that query the database), it is better to have the @Transational(readOnly=true) on it, but since I didn't understand - till now- much more, I'll choose not to use this annotation so I can deal with my laziness objects in the controller layer)

Interesting classes to see the source code of:
1. TransactionInterceptor: class source code to see what is happening internally. (very interesting)
2. TransactionAspectSupport:
  a. method: invokeWithinTransaction
  b. method: completeTransactionAfterThrowing (it shows
3. AbstractPlateformTransactoinManager
 a. method: commit (it shows the rollback if done if "setRollbackOnly" method is being called

The post above is based on my thoughts and is might not be valid.