Hibernate configuration and setup in a web applications

Overview

The steps are: create a Hibernate configuration file, create a SessionFactory with it and get a Session.
This is usually done during the loading of the web application context so that database verification/update/creation will be done upon the application's deployment instead of on first use.

Hibernate.cfg.xml

This file defines your data source, entities and configuration. This file “should” be placed in your application's root build path for ease of setup. However, if you have need to, it can be placed anywhere within you application's build path. I would recommend you keep it in the root of your build path unless you have a reason not to as you will need to reference the path when creating your SessionFactory. Below are a couple examples of a Hibernate.cfg.xml file.
For connecting directly to the database:
For connecting to a data pool managed by the application server:

Note: You'll notice that we're using “thread” as our session context class. This is the recommended way of using Hibernate within web applications. This means that we are going to have our session attach to the current running thread instead of managing it our self within the servlet life cycle. The implication is that when we use sessionFactory.getCurrentSession() we are getting the session attached to the thread which will automatically close when we do a commit or role back of a transaction. Since a standard unit of work maps well to the lifecycle of a servlet this works very well. We can call the sessionFactory via our singleton in HibernateUtil (see next session for more information) at any time to get the current session to do work without the need of passing it around. You will notice that I do pass the session object around in my examples and I don't really need to. However, I started off doing it that and I'd prefer to just stay consistent (and not have to update my prefab classes). Perhaps next time I have a big project I will redo my prefab method signatures and remove it.

HibernateUtil

The standard practice for interacting with a Hibernate Session is to have the a utility class keep the SessionFactory as a singleton.
In my case I chose to have the Singleton initialized within a static code block so that it will be instantiated when the class is loaded (which should be when you deploy the application). However, since this may differ from application server to application server I will also create a listener that will be called when the application context is registered. I know the listener makes the static code block initialization for the singleton moot but I like the non-standard singleton design pattern.
You'll also note the joinTransaction() helper method at the end. I find I don't often use a framework that does transaction management since I don't often write large applications and prefer a lighter, or no, framework. This method allows me to chain methods calls together to avoid duplicate code without the need of worrying if there is an existing transaction. Below is an example of how I use this method:
You'll notice that each utility method can be called on its own and complete its task but also methods that require another utility method can use them and the wont execute a commit if they weren't the method that was first called. This can be taken a step further if you have a more complex business layer which could manage the transaction it self.

HibernateListener

Next we create our HibernateListener class. This class is responsible for getting the session factory when the Context is initialized and closing it when the context is destroyed.

Sources

https://community.jboss.org/wiki/Sessionsandtransactions