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.
We also use @Transactional annotation to lock the record so that another thread/request would not change the read.
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.
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
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