Hibernate version: 3.1.3

I recently attempted to upgrade to 3.1.3 from 3.1 final and I have encountered problems with my unittests. Several of them quite reliably hang at the same location.

My question is, first, is anyone else experiencing this behavior and second is anyone aware of any changes in 3.1.3 that may have led to this? The only other time I've seen this problem is when the unittest has exhausted the number of connections in the pool (and needs another to retrieve a primary key).

As far as I can tell, hibernate3.jar is the only library file that has changed since 3.1 final.

I am using Spring and c3p0 and have seen the problem both on Oracle and SQLServer.

login as sys and monitor these two tables are your application runs...

v$open_cursor
v$session

OK, when I do this I can see that the numbers of sessions and open_cursors are greater for 3.1.3. For sessions, the number increases from 5 to 24 and for cursors from 5 to 36. 5 is about what I would expect, as that's the number of threads.

This is on Oracle, for SQLServer, I can surmise that the problem is similar from the log file:

2006-03-24 09:43:30.56 spid12 This SQL Server has been optimized for 8 concur
rent queries. This limit has been exceeded by 1 queries and performance may be a
dversely affected.

So, it looks like somewhere along the line I am leaking resources in 3.1.3 that I wasn't in 3.1 final?

hibernate uses connection pooling and caches the prepared statements, so that explains the resources - I guess I would make sure to determine if you are hanging due to hibernate vs a regular jdbc-program doing similar activity.

Create the same number of connections, and prepared statements - and see how it behaves from a jdbc program. Also realize that Oracle doesn't close cursors on functions that return ref_cursor. You have to surround these calls in a transaction. (even though it is only doing a query). (this only shows up on hibernate using stored-procs (functions) and the function returns ref_cursor).

Perhaps you can run through your code in a debugger and step through while monitoring these table.

One other item on closing cursors - if you use hibernate's Iterator off you Query, you can explicitly close the iterator which is supposed to close the cursor. I had no luck getting that working for the Oracle ref-cursor problem - it apparently only works on HQL and perhaps SQLQuery.

Yes, it requires more research. For now, I have dropped back to 3.1 final, which works. If I come up with any new information.

Your idea concering JDBC v Hibernate doesn't really explain the difference in behavior between 3.1.3 and 3.1 final. The other things you mention do not seem to be an issue, although I am seeing the hanging behavior on a few unittests, none of them are using query iterators or stored procs.

yes i agree - but the testing I am suggesting would give you greater insight into the problems, which may help move a *potential* bug in hibernate through the mill faster.

This could be a potential red herring, but it appears that the unittests which fail are the ones that test spring beans with a reference to a second session factory. What is interesting, is that it is enough (at this point) to have the reference, one of the test cases isn't even using the second session factory at the moment.

let us know what you come up with... thx.

Is there a list, which tests in 3.1.3 are expected to fail?

all the tests are under
<hib3install>/test directory

'N'

Sorry for explaining it not exactly. I mean, I have the source and I ran the test aka 'ant junitreport' and there are tests, which actually result in one or more errors/failures.

At least one test (org.hibernate.test.proxy.ProxyTest#testFullyLoadedPCSerialization()) obviously fails, since an entity was not deleted in testProxy() and thus the expected number of deleted entities does not match the number of entities created in testFLPCS. So this is expected to fail (or a bug, everyone knowns but has no time to fix).

So before starting to dive to deep into it, if there is a list, which says, yes testX ... Z are known to fail [with dialect N], than this would save me a lot of time chasing ghosts ...