I would like to reattach a session to an entity, and this entity has a one-to-many collection. During the transaction, the collection may have some add or update action, so it becomes dirty. But if this entity also has some other lazy loading properties, I will got the "collection is dirty" exception while I reattach Hibernate session to this entity.
How do I solve this problem, need your advise, thank you very much.

the session.refresh(Object) may solve your problem

Sorry, refresh() doesn't work.
In my application, there are more than 70 entities, you can imagine the one-to-many, many-to-one, many-to-many relationships amongs these entities. One entity may has lazy loading property which also has its own lazy loading property, and so on.
My transaction must have more than one request-response cycle to complete. If I close() session in each request-reponse cycle, I have no choice to lock() or refresh() entities if I need to get lazy loading property or collection. But lock() or refresh() only reattach current entity, if entity's property is an proxy, its sessino won't be reattached. I really suffer from it. It is impossible to put lock() everywhere in the application or entities. did anyone successfully use Hibernate to implement a real world MIS application? I must have something else to understand, please give me a advice to correctly use session.lock() or session.refresh().

thanks

Matt

"My transaction must have more than one request-response cycle to complete"
you have the solution on your requirement, if you don't close or disconnect your session on each request you're going into troubles!!!
Or course your app "seems" to work fine but if you simulate many clients connecting your app, you'll see big bugs.
The solution is to use thread local strategy for all business process that can be done in the request (for my team, it represents 95% of the case), this disconnect the session on each request.
But if you need more than one request, you have to "override" the threadlocal strategy by:
- stroring temporary data (not persistent objects) into the httpSession and by working with the hibernate session at the last request and commit
- or by storing the hibernate session into the httpSession

Our team uses the second solution for the 5% of cases that cannot be covered with the threadlocal strategy.
But be carefull storing the session into httpSession.... it's for specific needs.

Perhaps you should try using a "long session". Use a single session that spans multiple requests, and disconnect() the session between requests. All this is described in the documentation.

And by the way, the way to avoid the exceptions is to use update() instead of lock() for a dirty object. Once again, this is described in the documentation.

May I ask a question: do you have much experience writing web applications? And have you used another object persistence solution like entity beans before?

gavin, who are you asking the question?

This is the good way, a good way is to store state on client in "hidden" form fields too, but it is not a good idea to store hibernate or DB session in http session.

mattjiang

thank you guys,
As you mentioned above,
1) Yes, I do implement the threadloacl strategy in my Servlet Filter. And I have considered the concurrent clients hit to my application, it works fine. I even post my Filter source on the forum, you can search it.
2) Yes, due to these concurrent user, due to the HTTP session state maintenance, these state of entities are stored in the HTTP session.
3) Yes, no Hibernate session stored in Http session.

To delpouve:
Thanks for your advice,
1) I ever tried the session.disconnect()/reconnect() strategy, but it seems beings another problem. I ever got "You can't deference an collection, while it is "all-delete-orphan", but actually I never deference it.
2) If the reason to use update() is just to avoid lock() exception, I still want to know the correct way to use lock(). I will look into documents first.
3) You are experts, I won't say I have much experiences on something or something. But I ever developed some web based applications, and some of them use EJB. I think I know these basic concept to build a multiple users application.

ok, back to my problem, I still want to know how to use session.lock() or update(), and use disconnect()/reconnect() instead of close().
Maybe I need get back to study documents again.
Thank you very much

Sorry I put the wrong name in my response.
"To delpouve:" needs be corrected to "To gavin",
but also thanks a lot to baliukas, delpouve.
Hope I can learn more from you.

OK then, so what you should think about is that Hibernate persistent objects can be used exactly like entity beans if you find that using detached objects or long sessions is causing you problems. Personally, I have no problem using any of the three approaches, because I am very disciplined about understanding exactly the state of all objects with respect to persistence. But your needs may vary. Certainly, none of these problems will affect you if you use Hibernate like entity beans.

Try to implement application without this feature, it is very dangerous too.
It must be more simple to store session state in hashtable (if you use struts then you can use session scope form objects ). It will work as transaction per request for DB, it can break your transaction semantics in theory, but "reconnect" will break it in the same way and it is more diffcult to understand.

baliukas:
"it is not a good idea to store hibernate or DB session in http session"
In fact there are some case we can't use: "- stroring temporary data (not persistent objects) into the httpSession and by working with the hibernate session at the last request and commit"

We know that storing session into httpSession can be dangerous. That's why we only pass by business factories and dao factories, we have a lot some "rules" to prevent bugs due to httpSession expires...

Can you tell me what are the risks about putting session into httpSession? it's just to know if i've covered all the risks.

Is someone interested about the Session management by factories?

personally, I can't see why it is any more dangerous to keep a Hibernate Session in the HttpSession than any other nontheadsafe object.

There are three "dangerous" things:
1. It is not thread safe
2. Laeks memory
3. Leaks connections if not diconnected
It is possible to solve, but it is more easy to use old good CGI ways and to try optimize it with global cache and connection pool.