Pool becomes exhausted after exceptions equal to or greater than pool size

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Pool becomes exhausted after exceptions equal to or greater than pool size

Mondain
Hello fellow BTM users!

Ludovic suggested that I post my issue here, so here it is.. I see the pool becoming exhausted when exceptions occur and not being re-filled. The exceptions I use to test are PK violations, which could easily happen in a normal system. The bug report with a sample project (unit test included) may be found here: http://jira.codehaus.org/browse/BTM-27
Lastly, don't let your answer be any of the following: "Use MySQL" or "Use Postgres" or "Use Oracle"
I have no say in what DB is used on the project to which this example was derived.

Thanks,
Paul
--
http://gregoire.org/
http://osflash.org/red5
Reply | Threaded
Open this post in threaded view
|

Re: Pool becomes exhausted after exceptions equal to or greater than pool size

Ludovic Orban
Administrator
Hi Paul,

Sorry for the late answer.

What did you find unclear in the comments I entered in the JIRA bug ? BTM works fine together with SQL server so you should not worry about this.

Let's just talk about the testPoolExhaust and testPoolExhaust2 since those are the real important ones to you.

IMHO, testPoolExhaust works fine. If you run it on a clean database, it will succeed. When the database contains records, it fails on line 103. The assertion fails because the DAO could not insert the new row: since your primary keys are constant, the second run tries inserting the 5th row and fails because the PK has already been inserted by the previous run.

Make the PK truly random for the row insertion below the '// now try to add something' comment and your test then works fine.

testPoolExhaust2 fails because the FooDao.createFoo2() leaks connections. When the stmt.executeUpdate() line gets executed, it throws an exception. Since the c.close() call is not in the catch nor the finally block the connection is never closed: your code leaked. Put the c.close() in a finally block, make the PK generation after the '// now try to add something' comment random and the test just works fine.


Ludovic

Reply | Threaded
Open this post in threaded view
|

Re: Pool becomes exhausted after exceptions equal to or greater than pool size

Mondain
Ludovic,
First I want to thank you for your project, it was very easy to get going and seems quite fast. I'm a core dev on an open source project myself (Red5), so I know how thank-less it can be to provide support.
So on with my problem; I think that I was not very clear. I want to cause exceptions because I thought that was the root of the leaking connections. The step that I will take next is to use the block of code that has the connection close in the finally section. If you are correct this should work :)
I also need to clean-up my hibernate usage and I must say that it really irritates me that the TX API is broken in the latest hibernate!! But that is their fault, not ours.

Thanks,
Paul

On Fri, Aug 29, 2008 at 4:22 AM, Ludovic Orban <[hidden email]> wrote:

Hi Paul,

Sorry for the late answer.

What did you find unclear in the comments I entered in the JIRA bug ? BTM
works fine together with SQL server so you should not worry about this.

Let's just talk about the testPoolExhaust and testPoolExhaust2 since those
are the real important ones to you.

IMHO, testPoolExhaust works fine. If you run it on a clean database, it will
succeed. When the database contains records, it fails on line 103. The
assertion fails because the DAO could not insert the new row: since your
primary keys are constant, the second run tries inserting the 5th row and
fails because the PK has already been inserted by the previous run.

Make the PK truly random for the row insertion below the '// now try to add
something' comment and your test then works fine.

testPoolExhaust2 fails because the FooDao.createFoo2() leaks connections.
When the stmt.executeUpdate() line gets executed, it throws an exception.
Since the c.close() call is not in the catch nor the finally block the
connection is never closed: your code leaked. Put the c.close() in a finally
block, make the PK generation after the '// now try to add something'
comment random and the test just works fine.


Ludovic


--
View this message in context: http://www.nabble.com/Pool-becomes-exhausted-after-exceptions-equal-to-or-greater-than-pool-size-tp19194315p19218076.html
Sent from the Bitronix Transaction Manager mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
http://gregoire.org/
http://osflash.org/red5
Reply | Threaded
Open this post in threaded view
|

Re: Pool becomes exhausted after exceptions equal to or greater than pool size

Ludovic Orban
Administrator
Hi Paul,

I got your point about generating exceptions with duplicate PKs. My point was that there are two bugs in your tests that make them fail: a connection left unclosed and an assertion failure on a PK that should not be a duplicate but that actually is.

Ignore the Hibernate TX API, it's worthless when you're using JTA. I recommend you to carefully study the Hibernate integration page (http://docs.codehaus.org/display/BTM/Hibernate) to see how to configure Hibernate to integrate it well with the transaction manager and best practices on how to manage transactions. I know this page is outdated but it's going to be the next one I update.

In a nutshell, you tell Hibernate to rely on the TM for transaction lifecycle, bind the session's lifecycle to the transaction's lifecyle and use the JTA API to control the transaction.

If you have design questions, feel free to ask.

Ludovic
Reply | Threaded
Open this post in threaded view
|

Re: Pool becomes exhausted after exceptions equal to or greater than pool size

Mondain
I reconfigured a bunch of stuff in the config and the code, following Ludovic's direction and it all works fine. I made a blog post and submitted it to dzone if you guys want to take a look;
http://www.dzone.com/links/hibernate_transactions_with_btm_and_spring.html

Thanks
Paul

On Fri, Aug 29, 2008 at 10:13 AM, Ludovic Orban <[hidden email]> wrote:

Hi Paul,

I got your point about generating exceptions with duplicate PKs. My point
was that there are two bugs in your tests that make them fail: a connection
left unclosed and an assertion failure on a PK that should not be a
duplicate but that actually is.

Ignore the Hibernate TX API, it's worthless when you're using JTA. I
recommend you to carefully study the Hibernate integration page
(http://docs.codehaus.org/display/BTM/Hibernate) to see how to configure
Hibernate to integrate it well with the transaction manager and best
practices on how to manage transactions. I know this page is outdated but
it's going to be the next one I update.

In a nutshell, you tell Hibernate to rely on the TM for transaction
lifecycle, bind the session's lifecycle to the transaction's lifecyle and
use the JTA API to control the transaction.

If you have design questions, feel free to ask.

Ludovic
--
View this message in context: http://www.nabble.com/Pool-becomes-exhausted-after-exceptions-equal-to-or-greater-than-pool-size-tp19194315p19224042.html
Sent from the Bitronix Transaction Manager mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
http://gregoire.org/
http://osflash.org/red5