In conclusion, you're saying "never store hibernate session into http session"?
urgh, have to change my 5% use cases using it.... too bad

Probaly I too paranoid in this case,
but my coworkers did this mistake a few years ago (I have a lot of bad expierence myself too)

i thought it was quite "secure" knowing that for the apps i'm talking about, we cannot have simultaneous requests for the same httpSession... i did mistakes and i'll do other... everybody learns

I use Tapestry, so I store some session state in the Visit, equals to http session.
You mentioned some risks to store hibernate session in http session. But if we can gurantee there is only one client to use hibernate session and do disconnect or use connection pool. We still can use the session.disconnect() and reconnect() strategy, right?
I you agree this, please continue the following...
Because by using this, hibernate session should be stored in the http session. Each time the request gets in, hibernate session is retrieved from http session, reconnect, and be assigned to threadloacl in servlet or filter. After transaction goes end, hibernate session gets disconnected and put back to http session. Finally set threadloacl to null.
Is this also a solution to use hibernate session?

that's in parts, what i do when i need more than one request from the same client to manage a long transaction, but it seems this is not ok wait for baliukas or gavin response.

You need to implement some workaraund to make session thread safe,
user can click the same page twice without waiting the first request to complete (This problem was reported in forum too), frames, dynamic images (charts) can access session concurently, it is possible to prevent, but you must think about it on infrastructure level and it becomes "dangerous". It is very hard to find this kind of bugs, it depends on user input and UI changes can break session managemet.
Session level cache in httpsession is "dangerous" too,
if user closes browser before to complete "transaction" then you have a memory leak, it can produce problems on heavy load and it is amost inpossible to find the cause in production and can be hard to find in tests.

It is not very "bad" and it is possible to find solutions, but this kind of resouce management is "dangerous",
problems can be visible on heavy load and in production only (resource management depends on user input).

It is very easy to live without resouces like cache or connection in httpsession. I think it is a good way store session state on client (hidden form fields) It was very popular in CGI scripts, but it is a good way at this time too, It is more safe and not very hard to use. Hashtable in httpsession leaks memory too, but it is not so "dangerous" in practice if you store user input only without persistent state retrieved from db,
It is more easy to use than form fields on client.



[/quote]

it could be usefull to have an article "why not using httpSession" because if mattjiang and i had the same reflex, many people could do the same "bad practice".
For me it's not so dangerous because it's very rarely used and we are in intranet without complexe frameset can now i understand it can be a disaster if this practice is used too often.

Thanks a lot

i7[quote]Each time the request gets in, hibernate session is retrieved from http session, reconnect, and be assigned to threadloacl in servlet or filter[/quote]
You need to implement some workaraund to make session thread safe,
user can click the same page twice without waiting the first request to complete (This problem was reported in forum too), frames, dynamic images (charts) can access session concurently, it is possible to prevent, but you must think about it on infrastructure level and it becomes "dangerous". It is very hard to find this kind of bugs, it depends on user input and UI changes can break session managemet.
Session level cache in httpsession is "dangerous" too,
if user closes browser before to complete "transaction" then you have a memory leak, it can produce problems on heavy load and it is amost inpossible to find the cause in production and can be hard to find in tests.

It is not very "bad" and it is possible to find solutions, but this kind of resouce management is "dangerous",
problems can be visible on heavy load and in production only (resource management depends on user input).

It is very easy to live without resouces like cache or connection in httpsession. I think it is a good way store session state on client (hidden form fields) It was very popular in CGI scripts, but it is a good way at this time too, It is more safe and not very hard to use. Hashtable in httpsession leaks memory too, but it is not so "dangerous" in practice if you store user input only without persistent state retrieved from db,
It is more easy to use than form fields on client.



[/quote]

I am not. In fact, it is one recommended approach. Juozas has a different view, but personally I just don't find it that problematic to synchronize acces to the HttpSession. You would need to do it anyway.

Here is a quote from the book:

I agree with baliukas. User really might send second request to server by click submit twice before first request completes process. I think I know what "dangerous" means now...

But gavin seems to support storing hibernate session in http session. Besides thread safe consideration, user clicks submit twice or closes browser. There are critical points to be considered. May gavin give us some guides to store hibernate session in http session?

thank you all very much.

i'll use this solution, i will cover the risk for my apps

thanks a lot, i'm looking forward to read Hibernate in action in august.

Thanks for all your help.
I learned a lot.