Hello to every one.

I'm using Hibernate with Tomcat in a non-managed environment.

I'd like to know whether there is a limitation or not (apart from memory) in the number of opened sessions.
The point is that I would like to know if I must bind each Hibernate session to each Tomcat session, or if I have to make a session for each of our defined business task.

The latter solution, even if recommended in the documentation, would drastically increase the number of sessions (more than 20 sessions per user, at least).

Besides, with minimalistic sessions, I would waste the benefits of the cache, wouldn't I ?

So I'm wondering which pattern I will use.
If you also had this choice or if you know where I can find relevant information for that use case, please let me know.

Thank you in advance,
Joel.

IMO, Session per tomcat request is the best solution. You can use finer-grained sessions, but as you say, that is wasteful of cache resources. You can also use long-lived sessions, say one per user login, but that comes with its own difficulties. The ref docs give a brief outline of the pitfalls, but Hibernate in Action gives a better explanation (in chapter 5).

Undoubtedly there is at least one large article on this topic on the hibernate.org website, as it is one of the things that most stumps new users.

The most significant factor in determining the number of open sessions is the number of JDBC connections in your pool. This number is usually low enough (and should be low enough) to guarantee that sessions by themselves will never cause memory problems.

Thank you for your answer, and sorry for being so long.

That was the first approach. But since the user can handle an object in different manner (see it, modify it, verify the changes, remodify it,...) and that each operation is in a separate request, that doesn't make sense not to keep the cache between two requests.

What we are going to implement is a session per user task (it is a bit more general than a single operation), and this session will connect to the database when necessary and will be disconnected, if necessary, when the request has been processed (just before the hand goes back to tomcat)

I have already seen all those articles (A Short Primer On Fetching Strategies, Open Session in View, Sessions and Transactions,...) and some of the huge amount of posts in the forum. But I didn't found what I needed (particularly about pessimistic locking strategies), so I asked directly here.

Regards,
joel.

i think session per tomcat request is the convenient way , i dont think cache will be of much help unless we have data that are not changing frequently . and since session being a light weight in its creation and use , it wont create much problem .

any other sugestions ? :)

Session per request is "the safe way". Session can not be used as transaction local cache only (it is not thread safe), you can use 2L cache as optimization for correct concurrency control and to avoid scalability issues. Probably it is possible to reuse session, but it is not trivial and I do not think it a good idea for typical use cases (It must be better to use workflow/BPM stuff for multitransaction process ).

Thank you all for your replies.

The problem is that our system have to furnish the capability to (pessimistly) lock a data, so that no access will be available on that data until the user releases the lock. With a session-per-request pattern, the data will only be locked during the request, which is a bit short. Let see an example that will explain that in a simpler manner :

Let say A takes a data called d1
This data could be altered, so a lock is put on d1
A modifies d1 locally, on the browser, and then clicks on OK. The changes will then be propagated to the server.
If we don't keep a session opened (not the connection but at least the session) between the loading of d1 (one request) and the validation of the changes on d1 (another request), the lock could be lost, no ?

I know that optimistic locks could solve the problem but that's unfortunately not an option for now :|

All locks are released on commit, locking or HTTP session scope transactions can be used for very small scale intranet applications only.