We're about to create a new hibernate app which will be multithreaded.

So we have this:

BusinessObj
{
public ServiceA
{

}

public ServiceB
{

}
}


ServiceA and ServiceB will be called concurrently via RMI. Two clients can call a service simultaniously. Also, one client can call ServiceA while another client calls ServiceB

Should we put a Session/Transaction in each method?

Thanks.

i would suggest using a pool of hibernate sessions and have each method get one from the pool. Ofcourse this requires some more work as simply creating a new session in each method, but in the long run i think it is better.

Mr Mean

Isn't the session in ThreadLocal pattern what you need ?

Pooling Sessions is really not a good idea, IMHO especially because they are designed to be lightweight. You should stick to the approaches gavin described here http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/01/27#perf-problems

Well, this is a mounthful that certainly I don't comprehend.

Could someone please elaborate?

Does this approach work with my multithreaded RMI server?

Thanks.

Well if you don't understand it you should most certainly not use it :) I think for your simple case something like session-per-application-request should easily suffice. So just use one session and one transaction per request.

gloeglm kindly suggested:
"So just use one session and one transaction per request."

Well, my app is a multithreaded RMI server and my impression is that sessions aren't thread safe in Hibernate.

Anyone?

Exactly. So create a new one for every thread an place it in a ThreadLocal. Just look at the ThreadLocalSession pattern in the Wiki area.

But ThreadLocal has horrible performance and is not an option. If we were using JDK 1.4 - sure, but most of our customer's use 1.3 due to vendor lock-in (J2EE products)

Well you have to make sure somehow that a single session is only used by one thread at the same time.

Actually ThreadLocal performance should really be a minor factor in comparison to your JDBC and Network overhead. (even on 1.3)

Probably...

But what is the rationale behind not making Session thread safe? Does it prohibit scalability?

My impression is that the Hibernate philosophy is that transactions and synchronization are both things that should be handled by the application's container, not by Hibernate.

In other words, there are lots of possible strategies that you can use to handle transaction boundaries and synchronization boundaries, and different applications have wildly different needs. Any strategy would be wrong for some users.

ThreadLocalSession is almost always the right thing for any container that handles multiple requests, each with its own thread. But it might not be the right thing for other synchronization situations.

You don't mention whether your service is stateful or not, and how or whether you handle the synchronization of the state if so. If your service is stateful and reentrant, you will already have a lot of synchronization issues; adding Sessions to the mix just makes your already complex picture only slightly more complex. If your service is stateless and reentrant, then ThreadLocalSession is almost certainly what you want (and you can implement your own optimized version if JDK 1.3's is not swift enough for you!).

Cheers!
Rob

Container should handles this....? well, my app is an RMI server - hardly a container.

My RMI server does one thing: it uses hibernate to put and get objects. There are no other synchronization needs. The only problem is session objects, I think.