Hello,

While testing my webapp with Jmeter I realized my app has thread-safety issues, because of how I use Hibernate Session.

I use the 'open in Servlet Filter, put in ThreadLocal, assign to User, execute, close in Filter' approach.

The point is that each user has its own Session. Multiple users can access the app simultaneously - there are no thread issues there.

The problem shows if the same user accesses the app from multiple threads (think load testing with a single user, or a user who rapidly opens multiple app pages in several browser tabs).
What happens is that several transactions use the same Session, and since the Session is blindly closed in the Filter after each HTTP request, it is possible that the second transaction ends up trying to use a Session that has already been closed.

How do people deal with this type of situation?
Perhaps I could check/force Session re-connect right before each transaction, but that's messy, isn't it?

Thanks.
Otis

1 Hibernate session per HttpRequest
1 HttpRequest per HttpRequest thread
a transaction "belongs" to a connexion

So if a transaction tries to commit on a closed connexion... it means your transaction management is somewhere unsecure.

Have you noticed exactly which code is wrong? if yes show us

Woah! Really? Why? The problem is when the same user hits the app with multiple threads/requests in parallel. I don't think it makes sense to give each of those threads a new, separate, Hibernate Session, does it?

Thanks,
Otis

of course it does since Hibernate session is NOT threadsafe

what you can do if you want to continue like this is to add a servlet filter which allows only one concurrent httpRequest per session... I mean the second request will "wait" the first to be ended before being listening by the server

assign to user ? what does it mean exactly? put it on httpSession?

No, not HttpSession.
It just means that in the code that handles user requests and Hibernate Sessions keeps a mapping: User -> Hibernate Session.
That way, when a user makes a request, I first try to get Hibernate Session from there and call reconnect() on it. This way, I benefit from Hibernate Session acting as a cache, and I don't have to re-create new Hibernate Sessions for users that repeatedly request pages.


Regarding your comment above - I think you are right. I would have to either create multiple Hibernate Sessions for each user's thread. And I could queue up requests as you suggested above. Or, I could just declare my webapp not thread-safe for individual users making simultaneous requests. :)

i advice you to keep exactly 1 session per httpRequest (same user or not)
session is unexpensive and you are mistaken about "cache" aspect.
Try EHCache for second level cache, it's easy to configure.

And session.reconnect is to use if session has been disconnected not closed[/b]

Making a new Hibernate Session is inexpensive. However, once I start data that I already accessed, I would have to re-fetch it from DB if I were to use a new Session every time. That, I though, was the first level of cache - Hibernate Session 'remembering' data about previously loaded entities.
No?
Yeah, I do use session.reconnect() and session.disconnect().

Thanks!

if you want to keep loaded objects, read about detached and reattach in the doc

"session.reconnect() " is an anitipattern for many reasons.
It is possible to make this way thread safe with some fake attribute in httpsession and Filter, but I see no way to manage resources, your user becomes resource manager on server.

The most simple scalable way is to create session per request, but you will lose
performance. Workaround for performance is cache, a global object cache (independant on user count), content cache, query cache ("materialized view"),
indexes and configuration parameters.

There are more ways to increase performance than scalability and it is better to think about scalability first, it depends on application architecture.

I completely disagree.

I would propose that neither of these responses are useful, but I for one would be interested in more info. My app uses one Hibernate session per HttpRequest, as well as a 2nd-level cache provided by ehcache, but I'm always looking for better ways of doing things.
Scott

but what?

Gavin and Baliukas always have interesting things to say, what is the problem? We are on a forum... where people can help and talk... keep cool.

Anthony

Hmm, maybe something got lost in translation - I'm not hot at all. In fact, my eyes and ears are wide open for any good recommendations about how to manage Hibernate sessions in a web app. Gavin disagreed that session.reconnect() is an antipattern, but he didn't expand on it. Furthermore, most every forum topic I've read (and believe me, I've searched) and every wiki article I've studied seems to point to one Hibernate session per HttpRequest using a servlet filter as a best practice. Yet Gavin's line about session.reconnect() makes me wonder if there's a secret chef's recipe worth learning more about.

Gavin, I know you're very busy, but could you quickly point me to a URL or something to help me understand your perspective on optimal use of Hibernate sessions in a web app? Thanks in advance!
Scott

http://forum.hibernate.org/viewtopic.php?t=930018

there is a use case using reconnect explained