Announcement Announcement Module
Collapse
No announcement yet.
About session closing in HibernateDaoSupport Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • About session closing in HibernateDaoSupport

    Hi,

    Using a transcation manager (JTA on Weblogic), how Spring is closing the hibernate session when I call a manager method which use many HibernateDaoSupport.

    When I monitoring my Weblogic Jdbc Pool, I have many open connections open when only one transcation. And the connection are not closed after commit but with hibernate Session.finalize().

    In my DAO, my methods contains only, for example :
    Code:
    	public void save(BsContract audit) {
    		getHibernateTemplate().save(audit);
    	}

  • #2
    Assuming your TransactionProxyFactoryBean or BeanNameAutoProxyCreator instances are set up properly and you are actually doing transactional interception where you think you are, then the Hibernate Session will be bound to the current thread, once, and used for the entire transaction. When the transaction commits, the session will also be closed.

    One thing you might want to do is set the allowCreate flag in your HibernateTemplate to false (you can do this by feeding the DAOs a premade hibernate template from your context), and add in a HibernateInterceptor into your transaction proxy definitions. Then the interceptor will ensure that a Hibernate Session is created at the same time as the transaction, and you will get an error down below in your DAO if it tries to run when in fact there is no enclosing transaction with associated Hibernate Session.

    Comment


    • #3
      Originally posted by Colin Sampaleanu
      Assuming your TransactionProxyFactoryBean or BeanNameAutoProxyCreator instances are set up properly and you are actually doing transactional interception where you think you are, then the Hibernate Session will be bound to the current thread, once, and used for the entire transaction. When the transaction commits, the session will also be closed.
      In this scenario, if the session gets closed when the transaction commits, then doesn't that also mean that lazy Hibernate collections would become disconnected, and would throw a LazyInstantiationException upon subsequent usage? If so, how would you recommend handling lazy collections and transactions?

      Also (and very sorry if this is obvious in the doco but I can't find it), is there a run-down on how the different transactionAttributes affect this?

      Does the use of MySQL 3.x affect the way Spring transactions function, since it doesn't have support for real DB transactions?

      Thanks in advance,
      Scott

      Comment


      • #4
        if your session is closed then lazy loading will not work , if you want to keep your session open for a longer duration check out the open session in view pattern.

        Comment


        • #5
          Originally posted by sboulay
          if your session is closed then lazy loading will not work , if you want to keep your session open for a longer duration check out the open session in view pattern.
          Doesn't Spring already handle this for you if you're using the web ApplicationContext?

          Scott

          Comment


          • #6
            if your session is closed then lazy loading will not work
            This is always a bad idea. You need to span the transaction, too. Normally you should try to query the required part of the object graph, commit the transaction and enjoy the performance gain. Using lazy loading between two transaction is most troublesome and mostly not necessary.

            Comment


            • #7
              I did a bunch of research today in the old forums and discovered a bunch of posts between Matt Raible and Juergen on the topic of Hibernate, lazy loading and transactions. Helped a lot - I'll try implementing Spring's Hibernate filter this weekend and see what I get.

              Comment


              • #8
                Originally posted by Colin Sampaleanu
                Assuming your TransactionProxyFactoryBean or BeanNameAutoProxyCreator instances are set up properly and you are actually doing transactional interception where you think you are, then the Hibernate Session will be bound to the current thread, once, and used for the entire transaction. When the transaction commits, the session will also be closed.
                Juergon has posted you do not need to use the TransactionProxyFactoryBean et al. if you leverage the support in Hibernate for Weblogic JTA. I have my session-per-transaction scope set-up using this approach with no Spring Transaction Manager. I just leverage Spring for the DAO and session support. Seems to work pretty good, especially now that I can lazy initialize my VOs, but I am experiencing some transactional problems per my post under the EJB category.

                Hibernate property below:

                Code:
                <property name="hibernate.transaction.manager_lookup_class">			     net.sf.hibernate.transaction.WeblogicTransactionManagerLookup
                </property>
                HTH,
                Lou

                Comment


                • #9
                  With CMT

                  Juergen has posted you do not need to use the TransactionProxyFactoryBean et al. if you leverage the support in Hibernate for Weblogic JTA.
                  Yes, you can use Spring's Hibernate support within EJB CMT transactions if you like. However, even when using EJB these days, I tend to use BMT and let Spring do transaction management. For example, this means I can benefit from rollback rules, which have no EJB equivalent.

                  Comment


                  • #10
                    Re: With CMT

                    However, even when using EJB these days, I tend to use BMT and let Spring do transaction management.
                    I don't think I quite follow what you mean. If in your SLSB you start a new UserTransaction, it would just be demarcated there as if you were using CMT. How does Spring change things, unless you mean that you nest Sprng transactions under the UserTransaction??

                    Lou

                    p.s. I've been a fan since your first book. Your insights have been very helpful...thanks!

                    Comment


                    • #11
                      I use Spring tx mgt with the Spring JtaTransactionManager. Under the covers it obtains and uses the JTA UserTransaction. This means that I get a consistent programming model--I can test with local transactions, such as JDBC, Hibernate or JDO transactions. Also, I get the value-added features of Spring's declarative transaction mgt that EJB CMT doesn't offer, such as rollback rules. And I can test my declarative tx mgt in integration tests outside the container, which is a real productivity gain in my experience.

                      Comment


                      • #12
                        I use Spring tx mgt with the Spring JtaTransactionManager. Under the covers it obtains and uses the JTA UserTransaction
                        Rod, i see from what you've posted, the benefits of using JtaTransactionManager. Now, what if i want to use Hibernate with HibernateDaoSupport? Is this transaction manager kept in the configuration? What other configurations do i have to consider in order to make things work in a distributed transaction environment as if i where using HibernateTransactionManager?
                        I don't seem to understand the relation between Hibernate's transaction management and Spring's support for the former O/R mapping tool.

                        Greetings

                        Comment


                        • #13
                          The Hibernate support classes like HibernateTemplate and HibernateDaoSupport are agnostic to whether you are using HibernateTransactionManager or JTATransactionManager. To get the exact same semantics when moving from HibernateTransactionManager to JTATransactionManager, you would want to combine the latter with also using HibernateInterveptor on the tx declarations, otherwise Sessions will be bound on first creation, not at tx creation, but that's about it.

                          Comment

                          Working...
                          X