Announcement Announcement Module
Collapse
No announcement yet.
Spring stopped keeping session alive in lazy initialization Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring stopped keeping session alive in lazy initialization

    I had this working last week under a slightly different configuration and now I can't repeat what I did. Basically, I am trying to lazy initialize collections and it's complaining : "Failed to lazily initialize a collection - no session or session was closed " Before, Spring was taking care of this for me fine, even when I used "getHibernateTemplate().find()". Can someone take a look? Greatly appreciated...I just can't look at this anymore today.

    Gracious,
    Lou


    Here's the test case:

    Code:
    public void testUpdateClaim() throws DaoException {
           
            Long iRslt = null;
            ClmClaim clm = claimDao.findClmClaim(new Long(1096));
            ClmClaimExposure exp = createExposure();
            exp.setClaim(clm);
            clm.addToExposureSet&#40;exp&#41;;  //<<<<<<<< blows up on this line
            
            expDao.save&#40;exp&#41;;
            iRslt = exp.getId&#40;&#41;;
            System.out.println&#40;"+++++++++ ID saved&#58; " + iRslt + "+++++++++++"&#41;;
    
        &#125;
    The find method I have written is as follows:


    Code:
            Session s = SessionFactoryUtils.getSession&#40;getSessionFactory&#40;&#41;, false&#41;;
            try &#123;
                Object object = s.load&#40;getReferenceClass&#40;&#41;, id&#41;;
                //return getHibernateTemplate&#40;&#41;.load&#40;getReferenceClass&#40;&#41;, id&#41;;
                return object;
            &#125; catch &#40;DataAccessException e&#41; &#123;
                throw new DaoException&#40;e&#41;;
            &#125; catch &#40;HibernateException he&#41; &#123;
                throw SessionFactoryUtils.convertHibernateAccessException&#40;he&#41;;
            &#125;
    And my applicationCtx:

    Code:
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 
    	"http&#58;//www.springframework.org/dtd/spring-beans.dtd">
    
    <beans>
    	<!--Below is the following that you would use when testing outside the J2EE container-->
    	<bean id="clmDataSource" 
    		class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    		<property name="driverClassName">
    			<value>oracle.jdbc.driver.OracleDriver</value>
    		</property>
    		<property name="url">
    			<value>jdbc&#58;oracle&#58;thin&#58;@xxx.com&#58;1521&#58;nmad</value>
    		</property>
    		<property name="username">
    			<value>xxx</value>
    		</property>
    		<property name="password">
    			<value>xxx</value>
    		</property>
    	</bean>
    
    	<bean id="mySessionFactory" 
    		class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
    		<property name="dataSource">
    			<ref local="clmDataSource"/>
    		</property>
    		<property name="configLocation">
    			<value>classpath&#58;hibernate.cfg.xml</value>
    		</property>
    	</bean>
      
    	<!--Below is the following that you would use when testing outside the J2EE container &#40;no CMT&#41;-->
    	<bean id="myTransactionManager" 
    		class="org.springframework.orm.hibernate.HibernateTransactionManager">
    		<property name="sessionFactory">
    			<ref local="mySessionFactory"/>
    		</property>
    	</bean>
    
    	<!--Use an AOP interceptor to attach the Hibernate session to CMT for session-per-
    	  - transaction scoping.  This way one hibernate session will live with the transaction.-->	
    	<bean id="myHibernateInterceptor" 
    		class="org.springframework.orm.hibernate.HibernateInterceptor">
    		<property name="sessionFactory">
    			<ref bean="mySessionFactory"/>
    		</property>
    	</bean>
    	
     
    
    	<bean id="clmClaimDaoTarget" singleton="false" 
    		class="com.mitchell.services.technical.claim.dao.spring.ClmClaimHibernateDao">
    		<property name="sessionFactory">
    			<ref local="mySessionFactory"/>
    		</property>
    	</bean>
    	<bean id="clmClaimDao" 
    		class="org.springframework.aop.framework.ProxyFactoryBean">
    		<property name="proxyInterfaces">
    			<value>com.mitchell.services.technical.claim.dao.ClmClaimDao</value>
    		</property>
    		<property name="interceptorNames">
    			<list>
    				<value>myHibernateInterceptor</value>
    				<value>clmClaimDaoTarget</value>
    			</list>
    		</property>
    	</bean>
    	<bean id="clmClaimExposureDaoTarget" singleton="false" 
    		class="com.mitchell.services.technical.claim.dao.spring.ClmClaimExposureHibernateDao">
    		<property name="sessionFactory">
    			<ref local="mySessionFactory"/>
    		</property>
    	</bean>
    	<bean id="clmClaimExposureDao" 
    		class="org.springframework.aop.framework.ProxyFactoryBean">
    		<property name="proxyInterfaces">
    			<value>com.mitchell.services.technical.claim.dao.ClmClaimExposureDao</value>
    		</property>
    		<property name="interceptorNames">
    			<list>
    				<value>myHibernateInterceptor</value>
    				<value>clmClaimExposureDaoTarget</value>
    			</list>
    		</property>
    	</bean>
    	<bean id="claimDaoManager" 
    		class="com.mitchell.services.technical.claim.dao.ClaimDaoMgr">
    		
    		<property name="clmClaimDao">
    			<ref local="clmClaimDao"/>
    		</property>
    		<property name="clmClaimExposureDao">
    			<ref local="clmClaimExposureDao"/>
    		</property>
    		
    	</bean>
    	<!-- We don't need to do this since Spring is smart about going JTA if
    	  -  it exists, which in our case does when implementing with CMT.
    	  -  You would only need this for Spring-based CMT.
    	  -->
    	<!--<bean id="myClaimService" 
    		class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
    		<property name="transactionManager">
    			<ref bean="myTransactionManager"/>
    		</property>
    		<property name="target">
    			<ref bean="claimDaoManager"/>
    		</property>
    		<property name="transactionAttributes">
    			<props>
    				<prop key="save*">PROPAGATION_REQUIRED</prop>
    				<prop key="find*">PROPAGATION_REQUIRED</prop>
    				<prop key="update*">PROPAGATION_REQUIRED</prop>
    				<!-#-<prop key="someOtherBusinessMethod">
    					PROPAGATION_MANDATORY</prop>-#->
    			</props>
    		</property>
    	</bean>-->
    </beans>
    
    Hibernate.cfg.xml
    
    <hibernate-configuration>
    	<session-factory name="ClmSessionFactory">
    		<property name="dialect">
    			net.sf.hibernate.dialect.Oracle9Dialect
    		</property>
    		<property name="hibernate.max_fetch_depth">3</property>
    		<property name="hibernate.jdbc.batch_size">0</property>
    		<property name="hibernate.jdbc.use_get_generated_keys">true</property>
    		<property name="hibernate.jdbc.use_streams_for_binary">true</property>
    		<property name="hibernate.show_sql">false</property>
    		<property name="hibernate.use_outer_join">true</property>
    		<property name="hibernate.cglib.use_reflection_optimizer">true</property>
    		<property name="hibernate.query.substitutions">
    			true 'T', false 'F', yes 'Y', no 'N'
    		</property>
    		<!--
    			<property name="hibernate.transaction.factory_class">
    			net.sf.hibernate.transaction.JTATransactionFactory
    			</property>
    			<property name="jta.UserTransaction">
    			javax.transaction.UserTransaction
    			</property>
    			
    		<property name="hibernate.transaction.manager_lookup_class">
    			net.sf.hibernate.transaction.WeblogicTransactionManagerLookup
    		</property>
    		-->
    		<mapping resource="com/mitchell/services/technical/claim/dao/vo/ClmClaim.hbm.xml" />
    		<mapping resource="com/mitchell/services/technical/claim/dao/vo/ClmClaimExposure.hbm.xml" />
    	</session-factory>
    </hibernate-configuration>
    And my mappings:
    Code:
    <hibernate-mapping package="com.mitchell.services.technical.claim.dao.vo">
    	<class name="ClmClaim" table="CLM_CLAIM">
    		<id
    			name="id"
    			type="java.lang.Long"
    			column="CLAIM_ID"
    		>
    			<generator class="sequence">
    				<param name="sequence">CLAIM_ID_SEQ</param>
    			</generator>			
    		</id>
    		<version name="tcn" column="TCN" type="java.lang.Long" unsaved-value="null"/>
    		
    
    		<set
    			inverse="true"
    			lazy="true"
    			name="exposureSet"
    			cascade="save-update"
    		>
    			<key column="CLAIM_ID" />
    			<one-to-many class="ClmClaimExposure" />
    		</set>
    
    	</class>
    </hibernate-mapping>
    
    <hibernate-mapping package="com.mitchell.services.technical.claim.dao.vo">
    	<class name="ClmClaimExposure" table="CLM_CLAIM_EXPOSURE" lazy="true">
    		<id
    			name="id"
    			type="java.lang.Long"
    			column="CLAIM_EXPOSURE_ID"
    		>
    			<generator class="sequence">
    				<param name="sequence">EXPOSURE_ID_SEQ</param>
    			</generator>
    		</id>
    
    		<version name="tcn" column="TCN" type="java.lang.Long" unsaved-value="null"/>
    
    		<many-to-one
    			class="ClmClaim"
    			name="claim"
    			not-null="true"
    		>
    			<column name="CLAIM_ID" />
    		</many-to-one>
    
    	</class>
    </hibernate-mapping>

  • #2
    Some Logs

    Here's the log file. Somehow, Spring is thinking that it needs to close the session.

    Code:
    18&#58;39&#58;10,928 DEBUG SessionFactoryUtils&#58;183 - Opening Hibernate session
    18&#58;39&#58;10,990 DEBUG SessionImpl&#58;555 - opened session
    18&#58;39&#58;10,990 DEBUG HibernateInterceptor&#58;92 - Using new session for Hibernate interceptor
    18&#58;39&#58;10,990 DEBUG TransactionSynchronizationManager&#58;141 - Bound value &#91;org.springframework.orm.hibernate.SessionHolder@8698fa&#93; for key &#91;net.sf.hibernate.impl.SessionFactoryImpl@9dd6e2&#93; to thread &#91;main&#93;
    18&#58;39&#58;11,037 DEBUG TransactionSynchronizationManager&#58;117 - Retrieved value &#91;org.springframework.orm.hibernate.SessionHolder@8698fa&#93; for key &#91;net.sf.hibernate.impl.SessionFactoryImpl@9dd6e2&#93; bound to thread &#91;main&#93;
    18&#58;39&#58;11,037 DEBUG SessionImpl&#58;1982 - loading &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim#1096&#93;
    18&#58;39&#58;11,037 DEBUG SessionImpl&#58;2079 - attempting to resolve &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim#1096&#93;
    18&#58;39&#58;11,037 DEBUG SessionImpl&#58;2112 - object not resolved in any cache &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim#1096&#93;
    18&#58;39&#58;11,037 DEBUG EntityPersister&#58;416 - Materializing entity&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim#1096&#93;
    18&#58;39&#58;11,037 DEBUG BatcherImpl&#58;196 - about to open&#58; 0 open PreparedStatements, 0 open ResultSets
    18&#58;39&#58;11,037  INFO DriverManagerDataSource&#58;152 - Creating new JDBC connection to &#91;jdbc&#58;oracle&#58;thin&#58;@nmad.mitchell.com&#58;1521&#58;nmad&#93;
    18&#58;39&#58;11,412 DEBUG SessionImpl&#58;1906 - Version&#58; 0
    18&#58;39&#58;11,412 DEBUG Loader&#58;226 - done processing result set &#40;1 rows&#41;
    18&#58;39&#58;11,412 DEBUG BatcherImpl&#58;203 - done closing&#58; 0 open PreparedStatements, 0 open ResultSets
    18&#58;39&#58;11,412 DEBUG BatcherImpl&#58;261 - closing statement
    18&#58;39&#58;11,412 DEBUG Loader&#58;239 - total objects hydrated&#58; 1
    18&#58;39&#58;11,444 DEBUG SessionImpl&#58;2198 - resolving associations for &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim#1096&#93;
    18&#58;39&#58;11,444 DEBUG SessionImpl&#58;3929 - creating collection wrapper&#58;&#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmPolicySet#1096&#93;
    18&#58;39&#58;11,444 DEBUG SessionImpl&#58;3929 - creating collection wrapper&#58;&#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmPartySet#1096&#93;
    18&#58;39&#58;11,444 DEBUG SessionImpl&#58;3929 - creating collection wrapper&#58;&#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmLossObjectSet#1096&#93;
    18&#58;39&#58;11,444 DEBUG SessionImpl&#58;3929 - creating collection wrapper&#58;&#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmActivityLogSet#1096&#93;
    18&#58;39&#58;11,444 DEBUG SessionImpl&#58;3929 - creating collection wrapper&#58;&#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.exposureSet#1096&#93;
    18&#58;39&#58;11,444 DEBUG SessionImpl&#58;3929 - creating collection wrapper&#58;&#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmDiarySet#1096&#93;
    18&#58;39&#58;11,444 DEBUG SessionImpl&#58;3929 - creating collection wrapper&#58;&#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmAlertSet#1096&#93;
    18&#58;39&#58;11,459 DEBUG SessionImpl&#58;3929 - creating collection wrapper&#58;&#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmAttachmentSet#1096&#93;
    18&#58;39&#58;11,459 DEBUG SessionImpl&#58;2222 - done materializing entity &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim#1096&#93;
    18&#58;39&#58;11,459 DEBUG SessionImpl&#58;3112 - initializing non-lazy collections
    18&#58;39&#58;11,459 DEBUG HibernateInterceptor&#58;201 - Eagerly flushing Hibernate session
    18&#58;39&#58;11,459 DEBUG SessionImpl&#58;2242 - flushing session
    18&#58;39&#58;11,459 DEBUG Cascades&#58;497 - processing cascades for&#58; com.mitchell.services.technical.claim.dao.vo.ClmClaim
    18&#58;39&#58;11,459 DEBUG Cascades&#58;524 - cascading to collection&#58; com.mitchell.services.technical.claim.dao.vo.ClmClaim.exposureSet
    18&#58;39&#58;11,459 DEBUG Cascades&#58;506 - done processing cascades for&#58; com.mitchell.services.technical.claim.dao.vo.ClmClaim
    18&#58;39&#58;11,459 DEBUG SessionImpl&#58;2435 - Flushing entities and processing referenced collections
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2880 - Collection found&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmPolicySet#1096&#93;, was&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmPolicySet#1096&#93;
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2880 - Collection found&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmPartySet#1096&#93;, was&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmPartySet#1096&#93;
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2880 - Collection found&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmLossObjectSet#1096&#93;, was&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmLossObjectSet#1096&#93;
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2880 - Collection found&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmActivityLogSet#1096&#93;, was&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmActivityLogSet#1096&#93;
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2880 - Collection found&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.exposureSet#1096&#93;, was&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.exposureSet#1096&#93;
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2880 - Collection found&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmDiarySet#1096&#93;, was&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmDiarySet#1096&#93;
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2880 - Collection found&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmAlertSet#1096&#93;, was&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmAlertSet#1096&#93;
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2880 - Collection found&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmAttachmentSet#1096&#93;, was&#58; &#91;com.mitchell.services.technical.claim.dao.vo.ClmClaim.clmAttachmentSet#1096&#93;
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2776 - Processing unreferenced collections
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2790 - Scheduling collection removes/&#40;re&#41;creates/updates
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2266 - Flushed&#58; 0 insertions, 0 updates, 0 deletions to 1 objects
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2271 - Flushed&#58; 0 &#40;re&#41;creations, 0 updates, 0 removals to 8 collections
    18&#58;39&#58;11,475 DEBUG Printer&#58;75 - listing entities&#58;
    18&#58;39&#58;11,475 DEBUG Printer&#58;82 - com.mitchell.services.technical.claim.dao.vo.ClmClaim&#123;//all the stuff to insert&#125;
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2355 - executing flush
    18&#58;39&#58;11,475 DEBUG SessionImpl&#58;2820 - post flush
    18&#58;39&#58;11,491 DEBUG TransactionSynchronizationManager&#58;163 - Removed value &#91;org.springframework.orm.hibernate.SessionHolder@8698fa&#93; for key &#91;net.sf.hibernate.impl.SessionFactoryImpl@9dd6e2&#93; from thread &#91;main&#93;
    18&#58;39&#58;11,491 DEBUG SessionFactoryUtils&#58;348 - Closing Hibernate session
    18&#58;39&#58;11,491 DEBUG SessionImpl&#58;573 - closing session
    18&#58;39&#58;11,491 DEBUG SessionImpl&#58;3332 - disconnecting session
    18&#58;39&#58;11,491 DEBUG SessionImpl&#58;585 - transaction completion
    18&#58;39&#58;11,491 ERROR LazyInitializationException&#58;25 - Failed to lazily initialize a collection - no session or session was closed
    net.sf.hibernate.LazyInitializationException&#58; Failed to lazily initialize a collection - no session or session was closed
    	at net.sf.hibernate.collection.PersistentCollection.initialize&#40;PersistentCollection.java&#58;209&#41;
    	at net.sf.hibernate.collection.PersistentCollection.write&#40;PersistentCollection.java&#58;84&#41;
    	at net.sf.hibernate.collection.Set.add&#40;Set.java&#58;154&#41;
    	at com.mitchell.services.technical.claim.dao.vo.ClmClaim.addToExposureSet&#40;ClmClaim.java&#58;46&#41;
    	at com.mitchell.services.technical.claim.dao.junit.ClaimDaoSpringTester.testUpdateClaim&#40;ClaimDaoSpringTester.java&#58;136&#41;
    	at sun.reflect.NativeMethodAccessorImpl.invoke0&#40;Native Method&#41;
    	at sun.reflect.NativeMethodAccessorImpl.invoke&#40;Unknown Source&#41;
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke&#40;Unknown Source&#41;
    	at java.lang.reflect.Method.invoke&#40;Unknown Source&#41;
    	at junit.framework.TestCase.runTest&#40;TestCase.java&#58;154&#41;
    	at junit.framework.TestCase.runBare&#40;TestCase.java&#58;127&#41;
    	at junit.framework.TestResult$1.protect&#40;TestResult.java&#58;106&#41;
    	at junit.framework.TestResult.runProtected&#40;TestResult.java&#58;124&#41;
    	at junit.framework.TestResult.run&#40;TestResult.java&#58;109&#41;
    	at junit.framework.TestCase.run&#40;TestCase.java&#58;118&#41;
    	at junit.framework.TestSuite.runTest&#40;TestSuite.java&#58;208&#41;
    	at junit.framework.TestSuite.run&#40;TestSuite.java&#58;203&#41;
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests&#40;RemoteTestRunner.java&#58;421&#41;
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run&#40;RemoteTestRunner.java&#58;305&#41;
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main&#40;RemoteTestRunner.java&#58;186&#41;

    Comment


    • #3
      Please take a look at this post http://forum.springframework.org/showthread.php?t=9630

      HTH
      Last edited by Rod Johnson; Jan 18th, 2006, 11:06 AM.

      Comment


      • #4
        Thank you Omar, now that worked!!

        One thing though, these are just my unit tests. I actually will be using SLSBs to maintain the session there per each CMT method that is called where I want to use lazy init. inside a particular call. Will I have to front-end my DAOs with these code bits or insert them in each SLSB method call? I thought Spring manages the session-per-transaction bit automatically.

        Thanks much,
        Lou

        Comment


        • #5
          Spring can associate a Hibernate Session with a container's JTA transaction, even without a Spring transaction having to be involved. This is what this integration test verifies, for example:

          http://cvs.sourceforge.net/viewcvs.p....3&view=markup
          http://cvs.sourceforge.net/viewcvs.p....2&view=markup

          Now the HibernateTemplate needs to have the allowCreate flag set to true, so that the first usage will create a new Session, which will get synchronized to the CMT tx, and get used subsequently.

          Colin

          Comment


          • #6
            Originally posted by Colin Sampaleanu
            Now the HibernateTemplate needs to have the allowCreate flag set to true, so that the first usage will create a new Session, which will get synchronized to the CMT tx, and get used subsequently.
            Since I have my persistent code in DAO POJOs and I have no way of knowing which one will be called first, where would I initially create the session (i.e., set allowCreate to true)? Originally, I thought Spring takes care of this for you, but from your response it sounds like I need to initially demarcate the session once the CMT is invoked (i.e., inside the SLSB method).

            It seems like I hear conflicting things on this. I just want to put this one to rest, so please any information on this would be extremely grateful! :wink:

            Thanks,
            Lou

            Comment


            • #7
              I'm just saying that the HibernateTemplate you are using needs to have the allowCreate flag set to true. This means the (Spring) code will see that there is currently no Session bound to the current thread/TX, and ensure that one is created and bound to the thread and synched to the tx. After that it will be used for subsequent usages of HibernateTemplate with the same SessionFactory, with no new session being created.

              The flag is there so that in the cases where people are using HibernateTransactionManager, or alternately JTATransactionManager+HibernateInterceptor, they can turn if off and ensure that DAOs always assume a session is already available, which it should be in those cases. In your case, the allowCreate=true is needed to allow the usage in the DAO to force the creation. But there is nothing you have to do other than use the template.

              Regards,

              Comment


              • #8
                Thanks Colin...you know I think the difference is that I'm not using HibernateTransaction or JtaTransactionManager in applicationContext.xml - I'm using the Hibernate look-up manager class, per the following, in hibernate.cfg.xml:

                Code:
                <property name="hibernate.transaction.manager_lookup_class">
                	net.sf.hibernate.transaction.WeblogicTransactionManagerLookup
                </property>
                Rereading what Jurgeon had said on the topic, this allows a Hibernate session to automatically attach to the CMT. I configured this by turning on log4j DEBUG and sure enough, the session "keeps alive" till I see that transaction commit. I see now that I'm have a different issue, which I thought was originally a result of the transaction manager. I'll post that separately.

                Thanks again,
                Lou

                Comment

                Working...
                X