-
1. Re: Hibernate 3.0 MBean in JBoss 4.0 - JDBC connection relea
sebersole Oct 20, 2005 9:49 AM (in response to 101)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. -
2. Re: Hibernate 3.0 MBean in JBoss 4.0 - JDBC connection relea
101 Oct 21, 2005 4:26 AM (in response to 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! -
3. Re: Hibernate 3.0 MBean in JBoss 4.0 - JDBC connection relea
sebersole Oct 21, 2005 7:12 AM (in response to 101)"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(). -
4. Re: Hibernate 3.0 MBean in JBoss 4.0 - JDBC connection relea
101 Oct 21, 2005 10:11 AM (in response to 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. -
5. Re: Hibernate 3.0 MBean in JBoss 4.0 - JDBC connection relea
sebersole Oct 21, 2005 10:23 AM (in response to 101)actually, those two settings are mutually exclusive, used in different versions of Hibernate.
-
6. Re: Hibernate 3.0 MBean in JBoss 4.0 - JDBC connection relea
101 Nov 17, 2005 6:08 AM (in response to 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...