Hi There,
We are facing some performance issue with our new upgraded application. We recently upgraded our application platform
from :

Hibernate : 3.2.6.ga
Oracle : 10g
Weblogic :10.0

to :

Hibernate : 3.6.4.Final
Oracle :11g RAC
Weblogic : 10.3.4

The only reason why we upgraded hibernate is the Oracle 11g Dialect support. But there has been serious performance issues identified with this upgrade.Multi-datasource is configured with RAC instances in weblogic, i guess this should not be a problem. Whenever I start JMeter, in few seconds the datasource were going Overloaded in weblogic, and hibernate complains that
Well, before posting the performance issue, I've made some analysis with different hibernate versions. Since the Oracle 11g dialect support was added in 3.3.2 GA, i've grabbed the fixed class and patched my original version which is 3.2.6.g.
So i have two application, one with Patched 3.2.6.ga and one with 3.6.4.Final.

My application is working without any problem with patched 3.2.6.ga but 3.6.4.Final makes the weblogic datasource to overload.

Cracking my head to find out why it is behaving so.. Do you guys have any idea how to check and where. Or is there any real issues with Hibernate 3.6.4.Final as mentioned here

I appreciate your pointers.
Many thanks,
Mohan

Hi,
I don't think HHH-5790 should have such an effect, unless you're massively hit by it in a very specific use case. Anyway, issue is solved now.

There is no known performance problem, especially comparing to 3.2.x there should be only many improvements. I'd suggest to enable logging on the connection pool and verify that you don't have unclosed sessions / self opened stale connections?

Hi,
Sorry for latching on to this thread, but it seems relevant, so I thought I'd ask before opening a new thread.
I'm a hibernate novice, and I was wondering if something like Jmeter cloud testing (see example in link, that's what I found so far) would work with hibernate?
Thanks for any input, Suzanne

Hi Suzanne,
it depends on what you would like to test. It would certainly work, but you would be testing much more than the Hibernate operations only, as JMeter works on top of an HTTP interface you would need to make at least some very light servlet layer, and even then you could have bottlenecks or slowdowns in the HTTP network or servlets which would make it pretty hard to spot differences in different data structures used by Hibernate.
It could be useful if the goal is to test for example the performance of Hibernate applications in a cluster, measuring the full stack from session and second level cache distribution, but that would likely be out of scope from our usual interest in making sure the (Hibernate) core routines are optimised and make optimal use of databases, JDBC drivers and connections; the clustering performance issues should be addressed by the projects providing that layer of functionality, and the same logic should apply obviously to who provides the HTTP layer.

This is of course in the assumption that Hibernate is far faster than the other layers, which is usually the case; I've occasionally experienced customers needing help as Hibernate was the performance bottleneck and JMeter was being useful, but it usually boils down to incorrect configuration or wrong usage of the tool; so it might still be useful to spot significant configuration/design issues, but not of much use for us to spot performance regressions in the core code.