Subject Re: [Firebird-Java] Closing FBWrappingDataSource
Author Elias Holman
> FBConnectionPoolDataSource has shutdown() method. FBWrappingDataSource that
> wraps it does not have such method in all versions including RC4 (it will be
> there in release). However shutdown() is automatically called in finalize()
> call, so just simply forget the instance and garbage collector will do this
> automatically.
> If you want to be 100% sure that connections are released and you cannot
> wait till release, switch to the FBConnectionPoolDataSource. It has same
> interface (in release they both will implement FirebirdPool interface) so
> the change is almost trivial:

I have a test suite run inside JUnit, where I open up a series of
connection pools (one for each test), and because the garbage collector
could not run fast enough to close the old pool (I could call
System.gc() a lot, but I think that's a bit inelegant) before the new
one was up and running, there would be times that it would just hang on,
for example, a connection commit() because, I assume, one connection was
deleting tables that an old connection was still holding a reference to,
like in a PreparedStatement.

> You had something like that:


> New code would look like this:


Doing this change, and making an explicit shutdown() call on the
FBConnectionPoolDataSource after each test, fixed the weird hangs as
described above, so my hypothesis was seemingly correct. I think having
a shutdown() method in FBWrappingDataSource would be nice though, just
for code simplicity sake. Thanks for your help!

> > This is not part of the DataSource interface, for some reason. I tried
> > setting the maxPoolSize to 0, but that gave me a divide by 0 error.
> Hmmm... Can you tell the line number where it happens? Class is no designed
> to allow changing properties on the fly (in most cases this does not affect
> its behavior), but divide by 0 error should not happen in any case.

java.lang.ArithmeticException: / by zero

If I set maxPoolSize > 0 and then = 0.