Announcement Announcement Module
Collapse
No announcement yet.
@Transactional not working Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • @Transactional not working

    Hi,

    We are in the process of upgrading the Spring 2.5.6 to 3.0.5. Ours is a good working code base in 2.5.6 and we are using the
    Code:
    @Transactional(readOnly=false)
    on the business manager methods in which we need to have the Transaction boundaries and the business manager is annotated with
    Code:
    @Transactional(readOnly=true)
    . Once we upgraded to Spring 3.0.5 we are able Read/Create entities but we were unable to Update OR Delete the entities. Our ORM layer is Hibernate.

    Do we need to do any additional configuration parameter changes when we do the upgrade. Thanks in advance for your help on this.

  • #2
    If your DML statements aren't working you have improper tx management setup. Post your configuration.

    Comment


    • #3
      Below is my transaction configuration

      Code:
      	<bean id="oraSessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
      		<property name="dataSource" ref="projDataSource" />
      		<property name="entityInterceptor" ref="projDomainObjectInterceptor" />
      		<property name="eventListeners" ref="hibernateSessionEventListeners"/>
      		<property name="mappingLocations">
      			<list>
      				<value>classpath*:directory/path/*.hbm.xml</value>				
      			</list>		
      		</property>
      		<property name="hibernateProperties">
      			<value>
      				hibernate.dialect=org.hibernate.dialect.Oracle10gDialect
      				hibernate.show_sql=true
      
      				hibernate.format_sql=true
      				hibernate.use_sql_comments=true
      
      				hibernate.max_fetch_depth=3
      				hibernate.generate_statistics=true
      
      				hibernate.cache.provider_class=net.sf.ehcache.hibernate.SingletonEhCacheProvider
      				hibernate.cache.use_query_cache=true
      				hibernate.cache.use_second_level_cache=true
      				hibernate.cache.provider_configuration_file_resource_path=ehcache.xml
      
      				hibernate.bytecode.use_reflection_optimizer=false
      
      				hibernate.query.substitutions=true 'Y', false 'N'
      
      				hibernate.query.factory_class=org.hibernate.hql.classic.ClassicQueryTranslatorFactory
      			</value>
      		</property>
      	</bean>
      
      	<bean id="transactionORAManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
      		<property name="sessionFactory" ref="oraSessionFactory" />
      	</bean>	
      
      	<tx:annotation-driven proxy-target-class="true" transaction-manager="transactionORAManager" />

      Comment


      • #4
        Currently the DML is happening. The only change that we did updating the @Transactional(readOnly=true) to @Transactional(readOnly=false) on a single datamanger. This datamanger was used only by our custom HandlerInterceptor which was wired in
        Code:
        org.springframework.web.servlet.handler.SimpleUrlHandlerMapping
        org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping
        along with the
        Code:
        org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor
        in the servletContext.xml file.
        Did this caused the OpenSessionInViewInterceptor to misbehave in transactions boundary?. We are also still investigating on our end.
        Last edited by vbforums; Nov 19th, 2010, 12:25 PM.

        Comment


        • #5
          For those interested, we tracked down root cause on this yesterday. The issue stemmed from how greedily we were component scanning in the servlet context.

          Before:
          Code:
          applicationContext.xml
          
          	<tx:annotation-driven proxy-target-class="true" transaction-manager="txManager" />
          
          	<context:component-scan base-package="com.foo.bar"/>
          
          	<context:annotation-config />
          
          servletContext.xml
          
          	<context:component-scan base-package="com.foo.bar" />
          While running with Spring 2.5.6 we had no issues with this configuration and only after upgrading to Spring 3.0.5 did our mistake become apparent. I believe the result of this configuration is the component-scan in the servlet context is not only scanning the @Controllers, but it's going to re-scan all of our @Service/@Repo/etc components creating (non transactional) instances of them in this context. In this case, any of these dependencies wired into the controllers would result in non-transactional activity. At least, this is my understanding but I'd love to know if I'm off a little and/or what was changed between 2.5.6 and 3.0.5 that would have surfaced this problem.

          At any rate, the fix was simple -- only scan for @Controller.
          Code:
          <context:component-scan base-package="com.foo.bar" use-default-filters="false">
          	<context:include-filter expression="org.springframework.stereotype.Controller" type="annotation"/>
          </context:component-scan>

          Comment


          • #6
            Nothing has changed in that regard with component scanning, there have been some small changes to transaction management but not that grave. The problem you describe is a common mistake made with component scanning (regardless of the version).

            Comment


            • #7
              Thank you so much for posting your solution! It was a big help

              Comment


              • #8
                I had the same issue and had to spent 3 whole days before I came across the post. I did see the same behavior and i am using Spring 3.1. If you have greedy context scan if results in all non transaction objects even if you have @Transactional defined.
                Thanks a lot.

                Comment

                Working...
                X