I'm currently dealing with a codebase where the business code uses the #Transactional annotation from the javax.transaction package. However, this software also uses spring-data JPA repositories, which uses the Spring #Transactional annotation. Since we discovered this, we switched to using Spring #Transactional annotation on all newer business code.
My questions are:
Does using both different annotation cause any kind of problem ? I'm
guessing not because we discovered the problem during a code
refactoring but we didn't notice any defect related to this problem. However, I prefer to be sure
What's the difference in behavior between the two annotations ?
Thanks in advance.
Related
So, pretty straightforward question. Can I mix JEE annotations with Spring annotations on the same project? Are there any known issues with mixing both types of annotations?
For example, #Autowired and #Inject? #Named and #Qualifier?
Should Spring be able to solve injections without issues?
The reason I'm asking this is because I've encountered myself with some legacy code that uses Spring as CDI framework but 60% of the code uses JEE annotations. Some beans, however, are wired using #Autowired, there are also Spring ConfigProperties, etc.
I've already seen some weird behaviour, like classes not being injected, or #Named not being recognized by Spring, etc.
Spring does support CDI annotations, including #Inject, #Named, #Qualifier, ... But it comes with some limitations.
If some class is not injected, or #Named is not recognized, I think it is likely a configuration problem.
In Spring you can't simply call #Transactional method from the same instance, because of AOP-proxy thing. Would it be nice idea to make a self injection and call that method from self proxy instance? Do you see any drawbacks?
It is totally ok.
Moreover there was a Jira ticket for supporting this feature using #Autowired annotations. It's fixed in Spring 4.3+ versions. However for xml-based configuration or using #Resource annotation it's working in the earlier versions.
You can see the discussion bellow this ticket. #Transactional is one of the use case for this:
Particularly interested in #Async and #Transactional use cases.
I started persistence coding and I came across annotations such as #Transactional and #TransactionAttribute. I understand the basic functionality of these two annotations and also that they can be used at both class level and at the method level. What I would like to understand better is the difference between these two annotations. Any help would be appreciated. Thanks.
#TransactionAttribute is for EJB3 beans.
#Transactional is for POJOs (for example Seam, Spring/Hibernate).
#TransactionAttribute is meant for EJB beans.
#Transactional is meant for CDI beans.
No, #Transactional should not be used for annotating EJB business methods. While Java Docs suggests, it may be used for EJB, the EJB specs suggests it should not be used for EJBs at present.
I've read that the new way of creating Hibernate DAO is using Hibernate contextual sessions. The main reason being to avoid the Spring based HibernateTemplate/HiberateDaoSupport and thus Spring-Free DAO.
When I searched what to do with Exception translation? It's written everywhere that I should use #Repository! #Repository does need import and creates dependencies in my code. Am I right?
Aren't annotations considered dependency? If they are, is there anyway I can have that using XML? Or should I use the old HibernateDaoSupport way, since I'm going to have my code coupled with Spring anyway?
Update
Found a similar question: "integrate hibernate with spring without spring dependency in dao" but:
The first paragraph of the answer that #pap has given does not specify any clear XML alternative for #Repository.
The insight offered in the rest of that answer is plausible, yet my question remains unanswered that if decoupling is not much of a concern, why did Spring try proposing the new approach to Hibernate DAO?
P.S. This is not a criticism. It's rather an attempt to learn the proper way of thinking about this topic (i.e. the dependency).
The point of Spring exception translation in the first place is to break a dependency on Hibernate by creating a dependency on Spring. Regardless of the annotation, Spring exception translation catches a Hibernate exception and turns it into a Spring exception. By putting catch statements in your code tied to the Spring exception you are coupling your code to Spring far more directly than by adding any #Repository annotations. If you don't want to depend on Spring then simply use the Hibernate exceptions directly. Basically, there are two approaches:
Use Hibernate for exceptions and contextual sessions (no coupling to Spring). In this case, simply don't use Spring exception translation at all.
Use Spring for exceptions and session handling (looser coupling to Hibernate, additional coupling to Spring).
I need to use two different dataSources/transactionManagers for different methods. The concept with #Transaction(value="txManagerABC") and a defined qualifier in the applicationContext for the transaction manager is perfect. (As seen in Spring multiple #Transactional datasources)
Unfortunately I need to do the same thing with Spring 2.5. Does anyone have an idea how to solve this?
I believe the recommended way would be to fall back to XML transaction aspect configuration. If you really want annotations, you could probably make some modifications to the #Transactional annotation and surrounding infrastructure to make it work. Or you could update to Spring 3. There is very little to no compatibility issue between 2.5 and 3.
The problem is, the Transactional annotation does not let you specify a transaction manager , and one transaction manager can only manage one DataSource. but There's a way to do so by using JTA and JTOM , see how you can do it here