[Randy Burgess]

I have generated Spring DAO’s and I’m wondering if anyone has any suggestions on where the Hibernate session should be closed.

Eclipse 3.1.2
ME 4.1
oXygenXML 7.0
Log4E 1.0
KeepResident 0.2
FindBugs 0.17

WinXP SP2

[Riyad Kalla]

Moving to OT > Soft Dev

That depends on what you want, try reading this from the Hib team: http://www.hibernate.org/42.html

[Randy Burgess]

Yes but that is from the standpoint of using Hibernate exclusive of Spring. The generated DAOs use both HibernateTemplate (getHibernateTemplate) and Session (getSession). According to the HibernateTemplate API you don’t have to worry about handling the session if you use it, however it is limited compared to getSession().createCriteria. I’m using this in a Struts app running on JBoss 4.02. What did you guys have in mind on how to use these DAOs? Thanks!

[Haris Peco]

ultiweb,

Yes but that is from the standpoint of using Hibernate exclusive of Spring. The generated DAOs use both HibernateTemplate (getHibernateTemplate) and Session (getSession). According to the HibernateTemplate API you don’t have to worry about handling the session if you use it, however it is limited compared to getSession().createCriteria. I’m using this in a Struts app running on JBoss 4.02. What did you guys have in mind on how to use these DAOs? Thanks!

If you want that Spring do session and transaction management you can use Spring callbacks, but if you want more control use direct hibernate. I don’t tell you what is better for you – you decide.Spring doesn’t support all hibernate options, but make a lot ‘manual’ jobs

best

[Randy Burgess]

Actually I extracted an interface from the DAO and then wrapped the methods in transactions using Spring. Then I instantiated the interface instead of the concrete class because Spring returns a proxy of the concrete dao class wrapped with transactions, when configured properly. I found this to be the least amount of work, once you figure out what needs to change.

RB

[Haris Peco]

ultiweb,

Have you some suggestion for MyEclipse that you case ?

Thanks

[Randy Burgess]

I don’t understand the question?

RB

[Riyad Kalla]

RB,
snpe was asking if you had a suggestion of how to improve the default behavior in MyEclipse, possibly a use case that we didn’t consider that we should.

[dkittle]

I think the common way of dealing with closing a Hibernate session in a web application would be to write a filter that closes any open session after calling chain.doFilter(). Wrap the filter around your front controller (your Struts controller, for instance) and you’d be set. The calling sequence would be:
client requests a *.do page
servlet container runs your filter
your filter calls chain.doFilter()
servlet container run your front controller
front controller calls business logic that accesses database after starting a session
business method ends and returns to front controller
front controller ‘ends’ (which a redirect) and container returns to your filter
your filter closes the open session (MyEclipse and Spring both provide a threadlocal object to manage the session and expose a method to close the session)
your filter’s method ends which allows the servlet container to redirect to result page.

[Randy Burgess]

Yep, that’s one way to do it using a HibernateUtil object like the one ME will create for you but it’s my understanding that the Hibernate folks are recommending moving away from that pattern. Spring does have an OpenSessionInViewFilter that I believe will work like this but I haven’t played with it enough to say for sure.

Here is what I did. I renamed the DAO …DAOImpl, made the initDao method public, refactored an interface from the DAO using the original name and added references in my code to the interface instead of the DAO implementation. In my Spring applicationContext file the bean references the concrete class. All ME generated DAO’s could implement the same interface obviously. I then added the BeanNameAutoProxyCreator bean and the other associated beans referenced in this document: http://www.springframework.org/docs/reference/transaction.html#d0e6107, which wraps all my methods with transactions and handles opening and closing of the Hibernate session by using the PROPAGATION_REQUIRED transactionAttribute of the MatchAlwaysTransactionAttributeSource bean.

I then got my DAO’s by referencing the interface because the BeanNameAutoProxyCreator returns a proxy of of the implemented DAO class, otherwise you will get a ClassCastException when calling context.getBean(“myBean”).

So from my action subclass I could call:

ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
                "applicationContext.xml");
        
MyInterface mi = (MyInterface) context.getBean("myConcreteBeanReference");

Of course in this case now Spring is tightly coupled with the Struts action but you get the idea. It doesn’t take but a couple of minutes to do a couple of refactorings to the DAO.

Spring has other methods of wrapping your beans in transactions with automatic session handling that give you more control, at the cost of additional configuration or annotations. They’re all well documented in the URL above.

RB

[Author]

Posts