CODEWITHSUNDEEP
javaspringjpaspring-dataspring-data-jpa
Byron Voorbach
Byron Voorbach

Reputation: 4485

How to use @Transactional with Spring Data?

I just started working on a Spring-data, Hibernate, MySQL, JPA project. I switched to spring-data so that I wouldn't have to worry about creating queries by hand.

I noticed that the use of @Transactional isn't required when you're using spring-data since I also tried my queries without the annotation.

Is there a specific reason why I should/shouldn't be using the @Transactional annotation?

Works:

@Transactional
public List listStudentsBySchool(long id) {
    return repository.findByClasses_School_Id(id);
}

Also works:

public List listStudentsBySchool(long id) {
    return repository.findByClasses_School_Id(id);
}

Upvotes: 107

Views: 142013

Answers (6)

thiagoolivei_
thiagoolivei_

Reputation: 11

If you are using JPARepository currently it is not necessary to use @Transactional because it already provides for you.

Reference: https://docs.spring.io/spring-data/jpa/docs/current/api/org/springframework/data/jpa/repository/support/SimpleJpaRepository.html#save(S)

Upvotes: 1

ses
ses

Reputation: 13342

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.

  1. 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);
    }
  }

Upvotes: 3

menoktaokan
menoktaokan

Reputation: 506

We use @Transactional annotation when we create/update one more entity at the same time. If the method which has @Transactional throws an exception, the annotation helps to roll back the previous inserts.

Upvotes: 0

Zozo
Zozo

Reputation: 183

We also use @Transactional annotation to lock the record so that another thread/request would not change the read.

Upvotes: 0

Oliver Drotbohm
Oliver Drotbohm

Reputation: 83051

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.

Upvotes: 174

danny.lesnik
danny.lesnik

Reputation: 18639

You should use @Repository annotation

This is because @Repository is used for translating your unchecked SQL exception to Spring Excpetion and the only exception you should deal is DataAccessException

Upvotes: -1

Related Questions