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);
        }

---

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.

Quote:

---

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

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.

Quote:

---

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

Quote:

---

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.

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.

Quote:

---

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

Quote:

---

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.

Quote:

---

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!