db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <kahat...@apache.org>
Subject Re: JVM memory settings for running suites.All
Date Wed, 06 Jul 2011 18:53:41 GMT
Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:

> On 7/6/2011 9:35 AM, Knut Anders Hatlen wrote:
>> We should, but we just shut down the engine, we don't deregister the
>> driver in DriverManager, so the classes stay in memory forever. It's a
>> bit tricky to get the old versions unloaded. Simply calling
>> DriverManager.deregisterDriver() in the test tear-down won't work, since
>> it'll only let you deregister drivers in the same class loader as the
>> caller, and the test framework and the old drivers are loaded in
>> different class loaders.
> If we used DataSources for the upgrade tests would we avoid this
> problem or would the autoloaded driver still get loaded?

I think we already use DataSources for the upgrade tests, see
PhaseChanger#setUp(). In any case, EmbeddedDataSource will load
EmbeddedDriver, which will register itself with the DriverManager. We
can (maybe) change the EmbeddedDataSource to stop doing that, but we'd
still have the problem in all the old versions we test against.

One possible solution may be to create a helper class with a method that
unloads the embedded driver and somehow wire this class into the class
loader in which the old version is running. The helper class could be
used from the test tear-down. Then we should be able to trick
DriverManager into unloading the driver. I think...

I've filed DERBY-5316 to track this issue.

Knut Anders

View raw message