Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: domain of gcaddd-derby-dev@m.gmane.org
 designates 80.91.229.12 as permitted sender)
Mail-Followup-To: derby-dev@db.apache.org
To: derby-dev@db.apache.org
From: Knut Anders Hatlen <kahatlen@apache.org>
Subject: Re: JVM memory settings for running suites.All
Date: Wed, 06 Jul 2011 20:53:41 +0200
Lines: 31
Message-ID: <x6k4bvmea2.fsf@apache.org>
References: <4E146309.3000906@gmail.com> <x61uy3o20f.fsf@apache.org>
	<4E1489EF.2030709@sbcglobal.net> <x6sjqjmkon.fsf@apache.org>
	<4E14A174.6040605@sbcglobal.net>
Mime-Version: 1.0
Content-Type: text/plain
Mail-Copies-To: never
User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (usg-unix-v)
Cancel-Lock: sha1:dfa2I/dROWdVWleoCiqg+psejOc=

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