5

I have a problem, where Spring is injecting proxy to DAO object into service, but this service is injected into controller it is concrete class. This does not allow me to use service-wide transaction and launches transaction for each DAO call separatly. It's behavious I would expect.

Configuration:

Controller is class with @Controller annotation and constructor DI.

Service: 

@Component
@Transactional
public class UserServiceImpl implements UserService { ...}

Dao: 

@Component
@Transactional
public class UserDaoImpl implements UserDao {

JPA Config: 

<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>

<bean id="entityManagerFactory"
      class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean" >
    <property name="dataSource" ref="dataSource"/>
    <property name="persistenceUnitName" value="xxxPersistenceUnit"/>
    <property name="persistenceXmlLocation" value="classpath:META-INF/persistence.xml"/>
    <property name="jpaVendorAdapter">
        <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
        </bean>
    </property>
    <property name="jpaProperties">
        <props>
            <prop key="hibernate.dialect">${hibernate.dialect}</prop>
            <prop key="hibernate.show_sql">${hibernate.show_sql}</prop>
            <prop key="hibernate.format_sql">${hibernate.format_sql}</prop>
            <prop key="hibernate.hbm2ddl.auto">${hibernate.hbm2ddl.auto}</prop>
        </props>
    </property>
</bean>

<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
    <property name="entityManagerFactory" ref="entityManagerFactory"/>
</bean>

<tx:annotation-driven />

Anyone has any idea why is it happening?

mihn
  • 801
  • 1
  • 11
  • 22
  • I would ditch the '@Compoment' on the service and put the '@Service' stereotype annotation. As for the dao, I would put the '@Repository' annotation and ditch the Component annotation. Besides, a '@Transactional' attribute would mean each of the service's methods will have the same transactional propagation. I would annotate each of my methods separately depending on what they are supposed to do. – Nikola Yovchev Jan 29 '13 at 16:19
  • I added an answer, so please check that your transaction configuration xml file is processed by the same [app context](http://stackoverflow.com/questions/11708967/what-is-the-difference-between-applicationcontext-and-webapplicationcontext-in-s/11709272#11709272) where the user service are declared. feel free to ask further questions – Boris Treukhov Jan 29 '13 at 21:16

4 Answers4

5

Most likely your UserServiceImpl is created in the servlet context by mistake - please check context:component-scan expressions to check that only Controller classes are included there.

See @Service are constructed twice for examples of component scan filters.

For example if transaction manager bean and <tx:annotation-driven> are declared in the root web app context, then the transaction proxies will be created only for the beans in the root app context (from Spring Documentation):

BeanPostProcessor interfaces are scoped per-container. This is only relevant if you are using container hierarchies. If you define a BeanPostProcessor in one container, it will only do its work on the beans in that container. Beans that are defined in one container are not post-processed by a BeanPostProcessor in another container, even if both containers are part of the same hierarchy.

Less likely is that the transactional configuration of the user service is configured to use another transaction manager(or another default propagation), but in that case TransactionInterceptor invocation would be present in the stack trace of DAO method.

It's absolutely OK to have @Transactional on the DAO classes in Spring, if you understand what you are doing - the idea that repository or DAO cannot open transactions comes from the dark times when you had to create a boilerplate code to open transactions and it was hard to manage the transaction instances(and you could not be sure on how transactions are managed). But when you are using declarative configuration the things are not that bad. Spring promotes convention-over-configuration style where most methods use Propagation.REQUIRED transaction mode. In Spring Propagation.REQUIRED is the default mode when you decorate methods with @Transactional(this propagation is hardcoded to @Transactional annotation declaration), that means that the new logical transaction is mapped to the same physical transaction, so decorating your DAO classes with @Transactional is harmless.

See http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/transaction.html#tx-propagation for the reference on transaction propagation in Spring

In Spring Data JPA(I'm pretty sure that they know what they are doing), for example, CRUD methods on repository instances are transactional by default. That may be useful in some cases, the mechanism is same as when Hibernate allows you to get() some arbitrary objects from the Session for displaying without declaring an explicit transaction(of course it does not mean that the framework somehow manages to go without transaction - it's implicit in this case).

Community
  • 1
  • 1
Boris Treukhov
  • 17,493
  • 9
  • 70
  • 91
  • "Never say never" of course, but I would argue that in the vast majority of cases you will want to set your transaction boundaries at your service, as that defines logical groupings of your business units of work. The usage of the traditional `UserService` and `UserDAO` in the question would certainly suggest that the idiom is appropriate in this case. – ach Jan 29 '13 at 21:45
  • 1
    @ach Yes, you are right about the majority of cases. But IMHO these patterns(DAO/Repository) were published in 2003, before the frameworks with declarative transaction propagation became popular. I think that declarative transactions were available only with Java EE application servers(if you preferred to use a standalone TM with container you had to call TM methods directly), before Spring came out. Or you had to develop a custom AOP solution(and tell the team how to use it), but in Spring we don't have this problem - everything is tested and well documented. – Boris Treukhov Jan 29 '13 at 22:36
  • Hey. You were right. It it was problem with creating service beans in servlet context, not the root context. After addition of filter to everything works like a charm. – mihn Jan 30 '13 at 10:03
  • Thanks, this also helped me. I had the dispatcher-servlet component scan set to something very generic like "com.mycompany" which was also encompassing beans from the application context. – Forge_7 Oct 03 '14 at 16:07
2

I'm having a little trouble understanding what you're saying, but it appears that you're surprised that you're getting a new transaction for every DAO call, instead of just on the service call. Unfortunately, that's exactly what you've specified by putting "@Transactional" on the DAO class. Your DAO should not be transactional, at least if you're following the usual pattern. If I've understood you correctly, you should remove the @Transactional annotation on your DAO class.

David M. Karr
  • 14,317
  • 20
  • 94
  • 199
  • -1 I would be quite surprised too if I would get a new transaction in every DAO call too, when my application service is annotated with `@Transactional`(Propagation.REQUIRED is hardcoded as the default value of propagation in `@Transactional` annotation) ! – Boris Treukhov Jan 29 '13 at 19:35
  • @BorisTreukhov -1 to your comment. The OP is saying that his service is being injected as a concrete class (not a proxy), which means that it isn't transactional. Therefore, it would be expected for each call to a DAO method to execute within a new transaction (except in the case of DAO methods calling each other). – ach Jan 29 '13 at 21:36
  • @ach A) The OP has decorated DAO and Application service with transactional. B)Re `I have a problem, where Spring is injecting proxy to DAO object into service, but this service is injected into controller it is concrete class.` => The problem is that the service is a concrete class(not a proxy). – Boris Treukhov Jan 29 '13 at 21:43
  • @BorisTreukhov Yes, that's what I'm saying. But, you say that "you would be surprised too if I would get a new transaction in every DAO call"... you should not be surprised, because that's exactly the expected behavior if the Service is not Transactional. – ach Jan 29 '13 at 21:47
  • 1
    @ach did you notice `when my application service is annotated with @Transactional` part ? So I downvoted this post for excess sarcasm and misinformation. – Boris Treukhov Jan 29 '13 at 22:10
1

The other responders are correct in that you should not be annotate your DAO as @Transactional, but to really understand what is happening you should refer to the Transaction Propagation section in the Spring Reference Manual. The default propagation when using @Transactional is REQUIRES_PROPAGATION, so review that specifically.

Your question isn't that specific so I'm not sure exactly what you're looking for.

Edit: Upon re-reading your question it's possible that there may be an issue with your component scanning. Check to make sure that your <tx:annotation-driven /> is in the same application context where you're component scanning your service classes.

ach
  • 6,164
  • 1
  • 25
  • 28
0

You shouldn't use that "@Transactional" annotation in your DAO object. You are defining it in your Service and that will grant that all your DAOs methods, called inside a service method, are executed within the same transaction, which seems to be exactly what you want, when you say "service-wide transaction", right?

Also, as suggested, you might want to change your annotation from "@Component" to "@Service" in UserServiceImpl and to "@Repository" in UserDaoImpl.

Best regards.

Thiago Uriel Garcia
  • 142
  • 1
  • 9