So here is the skinny. I am about to give hibernate a shot for the first time. It is going to be used with struts in a web app which will be deployed to Websphere 5.1. Ive seen a method described on this forum for using an EJB module to contain the hibernate stuff, but I dont really want to go that route. I would prefer that hibernate just be part of the web application. My question is what is the best approch?

The way I thought of would be to create a servlet that would instantiate a SessionFactory and drop it in to the application context. From there in my struts actions, I would get a reference to the application context via the request and session and the retreave the SessionFactory. This does not seem like the most elegant solution. It would also make it impossible for any support classes to get access to the SessionFactory without haveing it provided as an argument to the support class.

I read in the tutorial about the HibernateUtil ThreadLocal method, but I'm a little cloudy about how that works. In the class defined in the tutorial, the SessionFactory is created in a static block, and then other classes get sessions from it via static methods. Wouldn't this require that the SessionFactory be instantiated each time a call is made to one of the static methods? Or does the fact that the SessionFactory is instantiated in the static block mean that it stays resendent in memory for the entier time the JVM is running. For give me if this seems more like a "beginner to java" question more than a "beginner to hibernate" question.

Thanks in advance
Chuck

Using the AppplicationContext is OK, but it has the diadvantage of having to pass the HttpServletRequest to everything that wants to use Hibernate, which conflicts with the whole MVC deal that Struts pushes.

The nice thing about ThreadLocal is that the SessionFactory gets created at VM start up, and is available from just about anywhere, without violating the MVC model (if you know what I mean...). It also eases your unit testing problems because it is much easier to simulate ThreadLocal than it is to synthesize a HttpServletRequest outside of the App server environment.

Actually, a static initializer is executed when the classloader loads the class for the first time :)

http://www.developer.com/java/other/article.php/2238491

Don't like developer.com, there was a good article on JavaWorld, but I can't find it anymore.

I stand corrected.

Thanks for the help guys.

Christian, that was exactly what I was looking for.

Ive been working with Java for a while, but I havent had a reason to really look at the way static initalization works, and I was working under the false premis that anything done in static initalization was done every time a call was made. I never really understood why you would initalize things staticly if that was the case. The whole concept now makes much more sence. I can think of at least 5 things Ive done where this would have made life alot easyer.


Thanks again for the help,
Chuck

Wait until you understand ThreadLocals, also very useful and unknown to many Java developers.

Funny you mention that. After reading the code for HibernateUtil.java, I did a quick google for ThreadLocal, and found a decent article about them. I understood what they were tring to do, but couldnt understand why you would need to do it. After you clerified the static init stuff for me, they make perfect sence, and as you said they seem very usefull.

By the way, a much more powerful HibernateUtil is in CaveatEmptor, http://caveatemptor.hibernate.org/

I don't like the ThreadLocal pattern myself. It is a very handy way of making sure you always have a hibernate session handy, but has a tendency to spread hibernate-specific code chunks all throughout the app, and can make managing transactions a little haphazard.

I prefer an MVC pattern with a simple Controller singleton that processes Request objects. For each request, it opens a session and maybe a transaction, invokes the request.process() method, then cleans up as appropriate. Then I build Request objects for each of the business requests, and a relatively simple mapping servlet which transforms http requests into business request objects. Not only does this reduce the direct dependencies on hibernate, it reduces the cost of adding other user interfaces (gui, cli, whatever). It's also a handy way to centralize access control, audit logging, and the like.

Anyone else use this type of pattern?

I have only three places with Hibernate-code if I use the ThreadLocal HibernateUtil: One is the HibernateUtil class, the other is my DAO.

Then there is an Interceptor, either a ServletFilter/WebWork interceptor/etc. or a proprietary application-server interceptor. Very nice and clean, it doesn't get much better. There are no dependencies (no code dependencies, no layer interdependencies) that would bother me. Sure, the interceptor has to run before and after my DAOs, no big deal. It seems like many people feel insulted by this interceptor. Don't, it's very natural and practical. It's the perfect usecase for interceptors. It doesn't introduce bad dependencies (there are several types).

Adding an IoC/etc. framework is overkill for this trivial problem, all you need is your app-servers support for interceptors or your web framework's interceptors. If you have none of these, a ServletFilter might be appropriate. And just because it has "servlet" in the name doesn't mean it creates a dependency on the UI layer.

I checked out the CaveatEmptor code - pretty nice stuff, clean, easy to follow, actually somewhat similar to what I describe, I just take the extra step of making my command processor also handle sessions, transactions, and whatnot. I guess that makes it IoC? Didn't seem like anything complex to me, just a clearer way to organize the code.

Anyway, thanks for posting that code. It's helpful to have real working application examples to compare notes against.