Hibernate 3.0 MBean in JBoss 4.0 - JDBC connection released

[101]

This is an important issue. We also have to patch jboss 4.0.3 by hand to alter this Hibernate property.

I don't understand how can this be an immutable default: it returns the jdbc connections to the pool without considering a possible running transaction? I may not see everything, but it was also leaking the jdbc connections for us.

I've checked the close calls to the hibernate session, and to the jdbc connections, and both was correct, and still I ended up with a full jdbc pool.

Turning off the aggressive release (with the patch) solved all our issues.

[sebersole]

First, not sure how a web service forum is the correct place for a discussion of Hibernate functionality... But that aside...

yli: why do you think that is a problem?

101: define "possible running transaction". The integration code assumes you are using JTA transactions and JTA DataSource. Is that the case? Sounds like not. I need to understand your setup to better understand what might need to change code-wise. BTW, setting the release mode to "on close" is typically on masking issues in your application code; hence why your solution may not be the best.

[101]

First, not sure how a web service forum is the correct place for a discussion of Hibernate functionality... But that aside...

Sorry, I was searching for this problem and just replied here...

101: define "possible running transaction". The integration code assumes you are using JTA transactions and JTA DataSource. Is that the case? Sounds like not.

I'm not sure how this works and I don't want to waste your time, but what happens if I have a running transaction (let's say a JTA transaction) in which I open a H session. In after statement aggressive release mode H closes (returns to the pool) the JDBC connection after each statement? How can it be done if the JDBC connection is opened in the transaction context? What happens at a possible rollback? How will the JDBC connection be rolled back?

I'm directly using Hibernate from the web layer, and I have an aspect that automatically opens/closes H sessions as needed. In case of an open() I also session.beginTransaction()/commit()/rollback() as needed. The aspect worked/works fine, I've even checked the JDBC connection.close() calls H invokes from the H log and it seemed also right (open/close balanced). And still the JDBC pool was exhausted, no idea why/how tough. It started with 4.0.3. So we started to look why and found this aggressive release suspicious, and turned off. It solved out connection leak problem, but I still don't see why.

I need to understand your setup to better understand what might need to change code-wise. BTW, setting the release mode to "on close" is typically on masking issues in your application code; hence why your solution may not be the best.

Well, all I know is that our open/close calls to the H session is balanced. Do I have to take care of any other things?

And from your response I suspect that if I start a JTA transaction before opening the H session then 4.0.3 would work fine with the default setup? So should I look up UserTransaction and begin a JTA transaction before H session open?

Thanks for you time!

[sebersole]

"101" wrote:

I'm not sure how this works and I don't want to waste your time, but what happens if I have a running transaction (let's say a JTA transaction) in which I open a H session. In after statement aggressive release mode H closes (returns to the pool) the JDBC connection after each statement? How can it be done if the JDBC connection is opened in the transaction context? What happens at a possible rollback? How will the JDBC connection be rolled back?

Well, within the bounds of a JTA transaction, multiple calls to DataSource.getConnection() return the same physical JDBC connection. Otherwise releasing connections after each statement would be silly, right ;)

"101" wrote:

... and turned off. It solved out connection leak problem...

To what did you set it?

"101" wrote:

And from your response I suspect that if I start a JTA transaction before opening the H session then 4.0.3 would work fine with the default setup? So should I look up UserTransaction and begin a JTA transaction before H session open?

See my comments above. Without the JTA transaction being in progress, I'm not sure what JBoss's behavior is regarding re-acquiring the same JDBC connection. If the same connection is not being returned, this would have potential hueristic transaction failure problems; but I just don't see how even this scenario would cause problems with connections being leaked.

Just to be clear, I know this works:

UserTransaction ut = ...;
DataSource ds = ...;

ut.begin();
Connection conn = ds.getConnection();
// do something...
conn.close();
Connection conn2 = ds.getConnection();
// do something more...
conn2.close();

ut.commit();

because both conn and conn2 above point to the same physical JDBC connection. But I am not sure how (or if) that works if that code is not wrapped in the ut.begin() and ut.commit().

[101]

To what did you set it?

I've changed these two lines:

settings.setProperty("hibernate.connection.agressive_release", "false");
settings.setProperty("hibernate.connection.release_mode", "after_transaction");

But I think when agressive_release is false, release_mode is not considered at all.

Thanks a lot for the answers, I'll try the UserTransaction scenario next week.

[sebersole]

actually, those two settings are mutually exclusive, used in different versions of Hibernate.

[101]

fyi, we ended up using 4.0.3SP1 with patching jboss-hibernate.jar to use AFTER_TRANSACTION.

using hibernate from the web layer (self started JTA transaction) with AFTER_STATEMENT jboss was leaking the actual oracle connections (no resource in pool exception after a few operations)

using hibernate from CMT beans with pristine jboss works fine!

patching jboss to use hibernate with AFTER_TRANSACTION works both for CMT beans and user started JTA transactions.

ps: warning, it all happened several days ago in a many hours long debug session. my memory _may_ trick me...