Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <449888ED.4050807@apache.org>
Date: Tue, 20 Jun 2006 16:46:53 -0700
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: [jira] Commented: (DERBY-1428) Generating derby properties on
 the fly can lead to non-deterministic engine startup behavior
References: <30795067.1150840530637.JavaMail.jira@brutus>
 <44987231.7050902@sun.com>
In-Reply-To: <44987231.7050902@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David Van Couvering wrote:

> I think the issue of derby.system.home and two databases running in the
> same VM is a symptom of a wider problem where I am not convinced we
> actually work running two instances in the same VM.  Derby makes use of
> a lot of system properties; if you have two instances, it seems to me
> that they will always be at war with each other when trying to configure
> Derby.
> 
> I would like to bet that if we built a test trying to do this sort of
> thing we would quickly find that it's problematic.  But not actually
> having done this test myself, I can't say for sure.  Has anyone tried this?

I think you are right, Derby uses system properties, well documentated
that it does, and there is only a single set of system properties. Thus
even with using classloading to have two Derby instances they are going
to share (probably not very happily) the same configuration for certain
items, like derby.log.

Dan.