Hibernate version: 3.1

Mapping documents: Irrelevant

Code between sessionFactory.openSession() and session.close(): get pojo, access collection

Name and version of the database you are using: Oracle


Hello,

i have a webapplication which uses one hibernate session per http user (with synchronized block to prevent 2 parallel hibernate request from same user) and use log running session pattern. So far so good. However, we find this very inefficient. Each user requesting data must do some calls to the database, and the datas are present in server memory in has much copies as there are http session. Because http session last for 8 hours, there can be lots of copies which each occupy about 20M of memory (150 "Employee" POJO/session * 150k picture/POJO = 21M / session). With about 30 sessions running at same time, we get 600M of hibernate data to store the equivalent of 21M raw datas.

Because 99% of user requests are read-only request (mainly, get list of phone numbers and picture of employees), we would like to share those pojo to all users, in a single application scope session. Now, we know the session is not thread safe, and we planned to make some synchronized block around sql request. But my question is, what will happen with lazy loading. If I share a read-only pojo with several thread, won't i get some troubles with lazy collection loading? Let's say Thread-A and Thread-B issue, at the same time a won't that cause troubles?

UP, nobody?

I think you are correct in your analysis of this problem. This could lead to both Thread-A and Thread-B trying to initialize the collection at the same time.

Since you say that 99% of the requests are read-only, wouldn't it be better to use a session-per-request for those requests? I guess the performance of this will be better than trying to synchronize access to a single session. If you configure a second-level cache your 20M of objects will be in there and Hibernate doesn't have to hit the database on every request.

If you really want to go on with the synchronization path you could check if it is possible to configure the web server to only use a single thread. I think this is more or less what you end up with if you try to synchronize access to the session. Performance will suffer from this and I don't think it is a very good idea.

a single thread would be out of question, it would affect performances so much, for now it's one thread / user, and i't only limited to requests that need the session, static ressource like pictures of pages are still served in paralle, so user does not see a performance bottleneck.

Displacing problem to second level cache could be a solution for the read-only request, and we will think about it, but i was afraid it would have a cost to convert, on each request, a good amount of object fro dehydrated state in 2nd level cache to hydrated state.

my question was answered i think :)