Hello,

I'm using Hibernate in a Servlet environment.
I use the ThreadLocal pattern to tie a Session to a Thread, so multiple entities can use the same Session, etc.

My concern is a multi-user environment:

Once the user A's request is done, and all Session work has been done, what should I do with the Session?
I understand I should leave it in ThreadLocal, so the next request (possibly user B) can get it.

However, should I be calling close() or disconnect() or something else on Session once I'm done using it?
Unless I close or disconnect the Session, I have a feeling that the next request, possibly from a different user (user B), will get a hold of still opened Session that user A used.

Isn't this going to result in problems and errors?

Thanks,
Otis

Hi,

of course you should close the Session at the end of User As request and use a new one for User B

Hello,

Thank you for the quick clarification!
2 more questions below.

I have changed my code to call Session's close() at the end of each user's request.

In order to get my code to work properly with this new setup, I had to add the following logic to the piece of code that retrieves Session from ThreadLocal:



I am trying to find out what exacly close() does and what exactly reconnect() does.
I looked at the Javadoc for Session, but it is rather sparse.

Does close() completely close the underlying JDBC connection, or does it merely return it to the connection pool? (I am using Hibernate with DBCP)


The Javadoc for reconnect() says "Obtains a new JDBC connection". Does that mean from the pool?


I am basically wondering what the performance impact of close() and reconnect() calls are.
If close() means "return JDBC connection to the pool", I'm happy. :)
If reconnect() means "get a new JDBC connection from the pool", I'll be happy again.

If either of those two methods skip the pool and completely close the JDBC connection or get a brand new (not pooled) JDBC connection, then I'll be worried about performance.

Thanks,
Otis

Hi,

session.close() does call close() on the connection - however, if your connection is from a pool, this will simply return it to the connection pool. You can not close() a session and later reconnect() it. In your case, the best thing you can do is once obtain a new session at the beginning of the request, and at the end close() it.

You can use disconnect/reconnect if you keep a Session open for a long time (for example in a HttpSession). Then you can disconnect the session to return the connection to the pool and not keep it occupied permanently by the session.

So what you should most likely do is just start a Session once at the beginning of the request, use it all the time, and at the end close it.

Ok, so close() returns it to the conn. pool. Good. I was able to reconnect() to it, as in the code I posted earlier.



What exactly is the difference between close() and disconnect() then? I can't tell from the Javadoc. Both seem to return the connection back to the pool, if the connection was obtained from the pool.



Thanks, that is what I am doing now :)
Otis

While I'm on this asking spree, another related question.

What about caches?

If I disconnect()/reconnect() a Session for each user request, will this impact caching?
More precisely, will this dis/reconnecting() still allow me to make use of the cache, or will this make Session run the same query over and over, without remembering the results between requests?

Thanks,
Otis

session.connect() will flush the session level cache while disconnect() , reconnect() will not. However in most cases just using one session for each request is the best alternative - you can allways use a second level cache like ehcache if you need caching.