Hi all,

I am a new hibernate user and I am currently building a web application with Hibernate 2.1.2, Spring and Tapestry.

I am wondering how (and where) I should retain business objects (beans) between each http request/response.

I read carefully hibernate docs and looked for answers to this in this forum but did not find any.

Basically, my application is some sort of eCommerce application where users may log in, put assets in a basket, etc...
- Therefore, there are some informations I need to keep between each http cycle (user logged in, basket, etc...).
- And I do not want to hit the database at each http cycle to get these informations.

I can think of different strategies :

1/ Keep the beans in my http session (actually, in Tapestry, this is a visit object but this is not important here). I don't like this because I'd like to keep my http session as light as possible and serializable for potential load balancing requirements

2/ Only keep bean's IDs in the http session and retain myself in some sort of singleton in the business layer the corresponding beans in maps where keys are the IDs. At each http request, I'd get the ID from the http session and then the beans from the maps.
This solution is actually making me maintain a cache but why not ?

3/ Only keep bean's IDs in the http session and rely on 2nd level JVM cache (ehcache for instance) to keep beans. Then, I would get them back at each cycle using load method.

I am sure I am not the first one to have to make such a decision. What are the advantages/drawbacks of each strategy considering the way Hibernate works ?

And yes, I have read the doc about Optimistic Locking/Versioning but this does not lead me to a clear answer.

Thanks a lot for your answers, remarks, references.

Regards

I'd say use 1. You can't do clustering/load-balancing anymore anyways if you use 2, at least not without serious effort. 3 might be okay too, but may produce additional database hits and has other nice effects in a cluster.

i use 1

Option 1 is given as a good option. However, I am also figuring out what to do and I am wondering what will happen in the following situation in a web environment:
(I use the Open Session in View pattern for the web pages)

- user logs in and the current user object (persistant) is stored in the session
- on another page I need to check the addresses of the person so I want to do currentUser.getAddresses(), however the user does not belong to the current session.

Off course I can lock the object again, but what will happen when two threads (say in a html frame environment) try to lock the user to a session at the same time?

What would be the best way to solve this issue?

you mean what will happen when two concurrent threads attack the same httpSession?
It is always possible and you're right, since hibernate session is not threadsafe, can be unsecure.
The best way for me is to add a servlet filter which accept only 1 concurrent request ... i've seen it before, it allows you to manage a stack of requests / httpSession

Anthony,


What I mean with a session in this case is the Hibernate session.

When a detached object is locked to one session and than another thread also tries to lock that same object. What will happen?

What I am wondering is the following.

I use the Filter to create a new session for every request. If the user logs in I store this object in the HttpSession. After the login request is finished this user object is detached automatically because the hibernate session is closed.

In every page I first want to check some properties of this user so I want to lock it to a hibernate session again and then use it. But because the web container can handle multiple HttpRequests at the same time the above situation can occur that the application tries to lock the object twice!

I guess this produces an exception, but what do other people do to get this construction working?

Just locking an object to two different sessions using session.lock(user, LockMode.NONE) is not going to cause a problem, in-and-of-itself. Even locking it twice to the same session will be OK.

What will get you into to trouble is 1) attempts to modify that user object if you are using optimistic locking, and 2) if the user object's graph contains persistent collections.