|Subject||Re: [Firebird-Java] Closing FBWrappingDataSource|
> FBConnectionPoolDataSource has shutdown() method. FBWrappingDataSource thatI have a test suite run inside JUnit, where I open up a series of
> 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
> 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:
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:<snip>
> New code would look like this:<snip>
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 triedjava.lang.ArithmeticException: / by zero
> > 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.
If I set maxPoolSize > 0 and then = 0.