Announcement Announcement Module
Collapse
No announcement yet.
Packaging webapp and transaction creation Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Packaging webapp and transaction creation

    When I package my classes into WEB-INF/classes the Spring @Transactional methods (or any of the methods that match the point-cut definition) that I have do not take part in a transaction. I am met with lots of 'No Hibernate session found, configuration does not allow...' exceptions in the logs. The puzzling thing is that in the stack trace I can see the CGLIB enhanced class so it does appear to be proxied but a new transaction does not seem to be created.

    However if I package the same classes into a jar file and place the jar in WEB-INF/lib, the application works fine! The transaction is created etc., Whats going on here?!? Why doesn't it work when the classes are under WEB-INF/classes?

    The Spring transactional configuration is:
    Code:
        <aop:aspectj-autoproxy proxy-target-class="true" />
        <context:component-scan base-package="com.example" />
        <tx:annotation-driven transaction-manager="txManager"/>
    
      	<bean id="txManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
        	<property name="sessionFactory" ref="sessionFactory"/>
      	</bean>
      
      	<tx:advice id="serviceAdvice" transaction-manager="txManager">     	
        	<tx:attributes>
          		<tx:method name="save*"/>
          		<tx:method name="update*"/>
          		<tx:method name="delete*"/>   
          		<tx:method name="*" read-only="true"/>
        	</tx:attributes> 
      	</tx:advice>
      	  	          
      	<aop:config>     	
            <aop:pointcut id="servicePointcut" expression="execution(* com.example.service.*.*Service*.*(..))"/>         	
            <aop:advisor advice-ref="serviceAdvice" pointcut-ref="servicePointcut"/>
      	</aop:config>
    I enabled Spring transaction logging and when the app starts up, I can see that:

    Code:
        28 Sep 2012 15:07:16,126 DEBUG NameMatchTransactionAttributeSource:94 - Adding transactional method [save*] with attribute [PROPAGATION_REQUIRED,ISOLATION_DEFAULT]
        28 Sep 2012 15:07:16,133 DEBUG NameMatchTransactionAttributeSource:94 - Adding transactional method [update*] with attribute [PROPAGATION_REQUIRED,ISOLATION_DEFAULT]
        28 Sep 2012 15:07:16,134 DEBUG NameMatchTransactionAttributeSource:94 - Adding transactional method [delete*] with attribute [PROPAGATION_REQUIRED,ISOLATION_DEFAULT]
        28 Sep 2012 15:07:16,136 DEBUG NameMatchTransactionAttributeSource:94 - Adding transactional method[*] with attribute [PROPAGATION_REQUIRED,ISOLATION_DEFAULT,readOnly]
    But when the time comes to actually work in the transactional method, it explodes with exception about not being allowed to create transaction.

    Code:
    org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: org.hibernate.HibernateException: No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here]
            at org.quartz.core.JobRunShell.run(JobRunShell.java:227)
            at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)
    Caused by: org.hibernate.HibernateException: No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
            at org.springframework.orm.hibernate3.SpringSessionContext.currentSession(SpringSessionContext.java:63)
            at org.hibernate.impl.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:698)
    Using Spring 3.1.2.

    Thanks!

  • #2
    For starters what on earth are you trying to do?! Your tx:advice and aop:config are useless as you want to use @Transactional (it is either that or your @Transactional/tx:annotation-driven is useless). So basically what you see in the logging is junk as that isn't being used.

    Your stacktrace indicates that you are trying to do something with quartz which at times is trouble some.

    Also you are using component-scanning and as you havea web application I assume you have both a ContextLoaderListener and a DispatcherServlet. Make sure you don't scan the same component twice (i.e. component-scan in both the CLL and DS scanning the same package).

    Comment


    • #3
      Originally posted by Marten Deinum View Post
      For starters what on earth are you trying to do?! Your tx:advice and aop:config are useless as you want to use @Transactional (it is either that or your @Transactional/tx:annotation-driven is useless). So basically what you see in the logging is junk as that isn't being used.
      Only one of them (the tx:advice or the tx:annotation-scanning) can be used in an application context? I removed the tx:annotation-driven (as of now I do not have any methods annotated with @Transactional) and just relied on tx:advice and the aop:config to do their thing but the problem still persists.

      Your stacktrace indicates that you are trying to do something with quartz which at times is trouble some.
      Can you please elaborate?

      Also you are using component-scanning and as you havea web application I assume you have both a ContextLoaderListener and a DispatcherServlet. Make sure you don't scan the same component twice (i.e. component-scan in both the CLL and DS scanning the same package).
      The component-scan is present only once.

      Comment


      • #4

        Only one of them (the tx:advice or the tx:annotation-scanning) can be used in an application context? I removed the tx:annotation-driven (as of now I do not have any methods annotated with @Transactional) and just relied on tx:advice and the aop:config to do their thing but the problem still persists.
        No you can use them together but in general when using @Transactional (which according to your starting post is what you used) adding a tx:advice with aop:config is overkill and might lead to duplicate proxies.

        Can you please elaborate?
        Without the full stacktrace that is quite hard, but depending on your configuration it can be that quartz uses an unproxied instance of your bean...

        Comment

        Working...
        X