How to use @Transactional with Spring Data?

Solution 1:

What is your question actually about? The usage of the @Repository annotation or @Transactional.

@Repository is not needed at all as the interface you declare will be backed by a proxy the Spring Data infrastructure creates and activates exception translation for anyway. So using this annotation on a Spring Data repository interface does not have any effect at all.

@Transactional - for the JPA module we have this annotation on the implementation class backing the proxy (SimpleJpaRepository). This is for two reasons: first, persisting and deleting objects requires a transaction in JPA. Thus we need to make sure a transaction is running, which we do by having the method annotated with @Transactional.

Reading methods like findAll() and findOne(…) are using @Transactional(readOnly = true) which is not strictly necessary but triggers a few optimizations in the transaction infrastructure (setting the FlushMode to MANUAL to let persistence providers potentially skip dirty checks when closing the EntityManager). Beyond that the flag is set on the JDBC Connection as well which causes further optimizations on that level.

Depending on what database you use it can omit table locks or even reject write operations you might trigger accidentally. Thus we recommend using @Transactional(readOnly = true) for query methods as well which you can easily achieve adding that annotation to you repository interface. Make sure you add a plain @Transactional to the manipulating methods you might have declared or re-decorated in that interface.

Solution 2:

I think that the question is a little bit wider and cannot be reduced on the annotations on the data access layer. We need to consider the entire stack of the application, the transaction strategies we want to apply and so on. There is a very comprehensive set of articles on this topic by Mark Richards on IBM developerworks site. You can find the first one here: https://developer.ibm.com/articles/j-ts1/

Best Regards

Solution 3:

In your examples it depends on if your repository has @Transactional or not.

If yes, then service, (as it is) in your case - should no use @Transactional (since there is no point using it). You may add @Transactional later if you plan to add more logic to your service that deals with another tables / repositories - then there will be a point having it.

If no - then your service should use @Transactional if you want to make sure you do not have issues with isolation, that you are not reading something that is not yet commuted for example.

--

If talking about repositories in general (as crud collection interface):

1. I would say: NO, you should not use @Transactional

Why not: if we believe that repository is outside of business context, and it should does not know about propagation or isolation (level of lock). It can not guess in which transaction context it could be involved into.

repositories are "business-less" (if you believe so)

say, you have a repository:

class MyRepository
   void add(entity) {...}
   void findByName(name) {...}

and there is a business logic, say MyService

 class MyService() {

   @Transactional(propagation=Propagation.REQUIRED, isolation=Isolation.SERIALIZABLE)
   void doIt() {
      var entity = myRepository.findByName("some-name");
      if(record.field.equal("expected")) {
        ... 
        myRepository.add(newEntity)
      }
   }

 }

I.e. in this case: MyService decides what it wants to involve repository into.

In this cases with propagation="Required" will make sure that BOTH repository methods -findByName() and add() will be involved in single transaction, and isolation="Serializable" would make sure that nobody can interfere with that. It will keep a lock for that table(s) where get() & add() is involved into.

But some other Service may want to use MyRepository differently, not involving into any transaction at all, say it uses findByName() method, not interested in any restriction to read whatever it can find a this moment.

2. I would say YES, if you treat your repository as one that returns always valid entity (no dirty reads) etc, (saving users from using it incorrectly). I.e. your repository should take care of isolation problem (concurrency & data consistency), like in example:

we want (repository) to make sure then when we add(newEntity) it would check first that there is entity with such the same name already, if so - insert, all in one locking unit of work. (same what we did on service level above, but not we move this responsibility to the repository)

Say, there could not be 2 tasks with the same name "in-progress" state (business rule)

 class TaskRepository
   @Transactional(propagation=Propagation.REQUIRED, 
   isolation=Isolation.SERIALIZABLE)
   void add(entity) {
      var name = entity.getName()
      var found = this.findFirstByName(name);
      if(found == null || found.getStatus().equal("in-progress")) 
      {
        .. do insert
      }
   }
   @Transactional
   void findFirstByName(name) {...}

2nd is more like DDD style repository.

I guess there is more to cover if:

  class Service {
    @Transactional(isolation=.., propagation=...) // where .. are different from what is defined in taskRepository()
    void doStuff() {
      taskRepository.add(task);
    }
  }