What's the difference between this two strategies(About creating Session):

Strategy 1:
Create an HibernateUtil,then use it within the servlet to create a ThreadLocal session:

import net.sf.hibernate.*;
import net.sf.hibernate.cfg.*;

public class HibernateUtil {

private static final SessionFactory sessionFactory;

static {
try {
sessionFactory = new Configuration().configure().buildSessionFactory();
} catch (HibernateException ex) {
throw new RuntimeException("Exception building SessionFactory: " + ex.getMessage(),

ex);
}
}

public static final ThreadLocal session = new ThreadLocal();

public static Session currentSession() throws HibernateException {
Session s = (Session) session.get();
// Open a new Session, if this Thread has none yet
if (s == null) {
s = sessionFactory.openSession();
session.set(s);
}
return s;
}

public static void closeSession() throws HibernateException {
Session s = (Session) session.get();
session.set(null);
if (s != null)
s.close();
}
}



________________________________________________________________________________________________

Strategy 2:
Create an HibernateUtil,but just create an singleton static SessionFactory in it.
Then in the servelt doPost() or doGet() method,use a sychronized block to get a session from the
given SessionFactory reference:

public class HibernateUtil {

private static final SessionFactory sessionFactory;

static {
try {
sessionFactory = new Configuration().configure().buildSessionFactory();
} catch (HibernateException ex) {
throw new RuntimeException("Exception building SessionFactory: " + ex.getMessage(),

ex);
}
}

public static SessionFactory getSessionFactory() {
return sessionFactory;
}
}


In the servlet:

public doGet(...) throws Exception {
doPost(...);
}
public doPost(...) throws Exception {
Session session = null;
synchronized(this) {
try {
session = HibernateUtil.getSessionFactory().openSession();
}
catch(...) {
...
}
}
...
}


In the strategy 1,each request(thread) keep one ThreadLocal Session.
In the strategy 2,each request(thread) has a method-local variable Session.

What's the difference? The strategy 1 is recommended by Hinbernate quickstart.If i use the

strategy 2,what's the disadvantages?

With first you get the same session through the whole thread. With second you get new session each time.
It depends what you want. If you have some sort of lazy loading it is probably best to have 1., since the session will stay opened. But if you need short non layz operation/transaction second might be useful too.

What's "sort of lazy loading" & "short non layz operation/transaction "

Can u give me an example?

Lazy: using proxies instead of actual objects or having collection associations which are by default lazy. And then using them for rendering in .jsp.

Non-lazy: simple save or update.

What is a whole thread? A request or a client?
If a client makes several requests sequencely,are there several threads or one thread?

Strategy 1 helps you to separate the layers of your application.
You can implement a DAO layer whose classes are using the HibernateUtil to get a Session, start a transaction, commit the transaction, etc. Since the Session is thread-local all DAOs are using the same Session, thus benefiting from the first-level caching mechanisms of the Session, but are still independent of each other.

As already stated by alesj you can use the same Session until your view (JSP or whatever) is prepared and then close the Session using a ServletFilter.

With strategy 2 you have to implement all your database logic in the servlet itself. You cannot separate the controller logic from the business logic.

A "whole Thread" in a servlet environment generally means a request. You post a request to a servlet engine. A servlet container thread will handle the request and ends with a response sent to the client. After the response is sent the Session is closed using a ServletFilter.
From request to response you can use the same Session with strategy 1.

If a client makes several requests sequencely they will be handled by different threads on the server side (or you don't know which pooled thread of the servlet container handles your request).

I see no disadvantages in strategy 1, only advantages, since it helps to build a layered application.

Thank u for your particular explaint.But there are a few questions i don't catch:

1.U said Strategy 1 separate the database operations details from the controlle layer,but Strategy 1 just get the Session from the HibernateUtil,if i don't use a DAO, i must write commit,save,delete ect in my controller servlet,but if i use DAO,i should pass the Session reference to the DAO as an argument,this also can work in Strategy 2,because Strategy 2 also return a Session Reference.

2.Why and How must i close the Session within a ServletFilter? A ServeltFilter has a doFilter() method to implement the filter details,but it works just before the request has been past to the specific Servlet,so i want to know, why and how must i close the Session within it?

With strategy 1 you don't have to pass a Session object to the DAOs. That's just the trick of the thread-local pattern. Each and every DAO object just has to use HibernateUtil.getSession() and they will all get the same object if they are used in the same thread.



You can work perfectly without it. It just makes things easier in my opinion.
You should always close the Session.
If you separated your controller from the view you may have a JSP (a view) which uses persistent POJOs to be displayed. These POJOs may have unitialized properties (because of lazy loading). If you closed the Session in your controller (the servlet) the uninitialized properties are not available any more and you will get an exception. If you want them to be available you will have to keep the Session open until the JSP is processed. Then you need a ServletFilter to do some cleanup e.g. close the Session.

It depends on the implementation of your doFilter method whether the work is done before the servlet's work or after it. It is something like: