It is said in the features list that Session is serializable, i've made loadbalancing tests and of course it is but i have one question:
- we have an HibernateSession
- we store it into the httpSession (ok we must have a good reason for doing this as it is not a "100% secured" idea)
- the client is loadbalanced
- the httpSession (and so hibernate Session) is now on the second server
- what happen with the jdbc connection used by hibernate? how is it possible to reuse our hibernate session which is not closed, not committed?

Thanks,
Anthony

Session.disconnect() disassociates the session from the JDBC connection. Session.reconnect() grabs a new one.

yes but we must commit the connection before "disconnecting" it.

The only way to deal with this is to work only with the httpSession and temporary object and at the "validation" httpRequest, use an hibernateSession to persist all the work.

Maybe i'm not clear so excuse me ;)

So? Whats the problem?

only that some (i insist it's not always the case) web use-cases need more than one jsp to create or modify a graph of objects.

If we don't want to lose data because of the loadbalancing, we should commit and disconnect for these cases knowing that for all the other cases threadlocal/servlet filter is used for example.

But this approach is a little bit more complex.
For example we need 5 jsp to cover a "creation", at the third jsp the user closes his browser or simply clicks the "cancel" button, what we need to do is a rollback over the 2 previous jsp... but we can't because of the 2 previous commit/disconnect.

That's why i'm talking about working only with httpSession,
- the first request will load what we need
- then all the modified / temporary objects should be stored in the httpSession
- at the final request (user click "validate" button), all the detached objects will be reassociated with a new session (or a reconnected one) and the version checking + commit can be done


Am i right?

Thanks Anthony

Session.setFlushMode(FlushMode.NEVER) is provided for this. However, I think the session doesn't like being serialized if it has unflushed changes. If you submit a JIRA issue about that, I will modify SessionImpl, so that an unflushed session may be serialized.

so if i understand:
we can use the same session with commit / disconnection / reconnection per httpRequest during several "jsp". The db won't be affected since no flush is done (Session.setFlushMode(FlushMode.NEVER)).
At the validation (last jsp), we just have to explicitly call
session.reconnect(); //no pb in case of deserialization
// make some job, or make nothing if the job has been done in previous
//HttpRequests (but without flushing)
session.flush();
tx.commit();
session.close();


But, in a loadbalanced environement, this can only be done if unflushed session is serializable
So as you said, the jira issue is created

http://opensource.atlassian.com/project ... wse/HB-896

Thanks again for explanation,
Anthony

Only if your HttpSession (where the Session would be stored in that case, probably) _has_ to be serialized. You can run a load balanced system without HttpSession failover, this is called Sticky Sessions.

yes i know about sticky session (we are using tomcat with mod_jk & sticky) but we need failover for some future apps.

For the moment we have planned to prototype 2 tomcats (release 5.x) clusters and are thinking about how to test frameworks, one issue is to test serialization of HttpSession containing Hibernate Session with "long" transaction, that's why i've posted this topic.
The first test was negative because the session wasn't disconnected before being serialized ... that is perfectly normal.

We also are thinking about porting our apps from tomcat to weblo, websphere or 10g (humhum no comment), the managers have not taken the decision yet, unfortunatly JBoss was not even tested (even if every developper knows about how competitive JBoss is, developpers don't decide).
But as we are not using EJB, the only needs will be to respect versions of J2EE (servlet & jsp), jdk ... i think there won't be serious problem about that.

I really appreciate all the tips and points of view you guys are giving!


Anthony