hi all,
we are using hibernate on a MVC architecture.
We use the threadLocal strategy on 90% of the cases.
We have some business process that need more than one JSP to allow the commit of the transaction.
For those cases, we place the hibernateSession into the HttpSession.
It works fine but there's a problem using a clustered environment:
- 1st : hibernate session is used to begin a transaction on tomcat1
- the session contains updated objects but we still don't want to commit yet
- the second form (jsp) is posted
- we have been loadbalanced, we're now on tomcat2
- we managed to get our hibernateSession (all our objects are serializable, it works fine)
- then we can get some objects pre loaded on it
- but if we load more objects or commit the changes, we have a this:
2004-02-16 17:54:28,438 WARN [org.apache.catalina.cluster.tcp.TcpReplicationThr
ead[3]] impl.SessionFactoryObjectFactory (SessionFactoryObjectFactory.java:148)
- Not found: 0e57bd68fabf3ac300fabf3ac9c80000
2004-02-16 17:54:28,438 WARN [org.apache.catalina.cluster.tcp.TcpReplicationThr
ead[3]] impl.SessionFactoryObjectFactory (SessionFactoryObjectFactory.java:138)
- Not found: null
16 f

je sais pas du tout !!!....

That must be the most useless post ever here.

As for the original question:
Do you have hibernate.session_factory_name set in your configuration?

in tomcat, we don't manage to set jndi name for session Factory... we're going to try using the datasource.

I don't think relying on Serialisation to transfer the SessionFactory between nodes is supported. You should really try to get your SessionFactory into JNDI, thats possible with Tomcat too, take a look here http://www.hibernate.org/114.html. However the SessionFactory relies on a session factory name set for retrieving the session factory on deserialisation ... So what I would suggest is:

- Bind the SessionFactory to Tomcat JNDI using the approach in the link
- Set the sessionFactory name to the JNDI name used in your binding, and ignore the error about not being able to bind the SessionFactory to JNDI

Lets see if this works out ...

Adding a JNDI binding of a Hibernate SessionFactory to Tomcat has some serious implications for classloading and the classloader hierarchy in a servlet container, see the page Michael posted.

hm, now that i think of it, probably it could even work by just setting the session factory name and ignoring the error about not being able to bind ... as long as a SessionFactory has been created sometimes on every node of the cluster.

thanks for all,
we'll try this tomorrow, it's 7pm here... (france).
I think there'll be a problem: the transaction is hold by a jdbcConnection which is used by the hibernateSession.
The JDBC connection is managed by dbcp.
So, if the hibernateSession began on tomcat1, how is the HibernateSession able to commit it on a tomcat2 ? it will never find the same connection?

I'll tell you tomorrow if it is succesfull.

A Session is always local to the VM, I don't recommend replicated HttpSessions for a Tomcat cluster (yet, there is some work done on fine-grained replication). So you would have a Session lifetime for a single Http request, as always. If you absolutely want the long Session approach with a disconnected Hibernate Session stored in the HttpSession for multiple request/response cycles, use sticky HttpSession handling for your cluster.

See the Wiki page about Session and Transaction scopes.

As I get this, you don't even disconnect the session at the end of a request? This will be an absolute performance killer, you will bind a JDBC connection for the lifetime of the Session! And I don't think this is possible at all in a cluster with HttpSession replication.

closing session is expensive but not disconnecting, it's different am i wrong?

Sticky session is of course recommended even if we don't manage to do this with tomcat / mod_jk (if someone know a detailled site... give it please, it is not well documented on the web). But we might prevent a server crash and so a session replication to another cluster. We're talking about a "critical" site of our company.

Of course, we know that 1 session per http request is the best but using httpSession for long (more than 1 requests) transactionnal business process seems to be the only way to do it. If someone knows another strategy, it could be usefull for many of us to detail it.

up

Closing/Disconnecting the Session after every request is absoltuely essential if you don't want to introduce a serious performance bottleneck. Doing transactions spanning multiple requests on a cluster surely is not supported by just leaving the transaction uncommited. I would strongly suspect this does not even work when using plain JDBC.

PS: Please stop that up stuff.

excuse i misunderstood your question, in fact:
- 90% of our business don't need long transactionnal, so we use threadlocal + servletfilter to manage disconnection
- for the other 10%, we "place" the Session in the httpSession disabling the threadlocal strategy

It's only for the 10% that we ask about clustering but it seems there is no solution for preventing a server crash and keeping the transaction alive on the second server.

Thanks for all,
We manage to use sticky session with tomcat 5 /mod_jk, if someone need help... we're her.