I have to agree with Dan -- I am a little uncomfortable using system
properties to share VM-global information. *Ultimately* what I would
like to see us solve is to actually allow multiple Derby instances to
run under different classloaders, but putting that aside for a moment,
couldn't we have a shared file or a system of lock files rather than
depend on system properties?
David
Daniel John Debrunner wrote:
Mike Matrigali wrote:
In the continuing discussion about how to fix DERBY-700, the
current most likely solution is to require one or more new
internally set system properties.
Basically there is a need to somehow in a single JVM to share
information from 2 classloaders, such that we can answer the
question of whether database X is currently opened by a
classloader in the current JVM. The proposal is to use the
java system property mechanism as the shared information point.
What information are you going to share that solves the problem? I guess
I must have deleted the e-mail about solving this issue with system
properties.
Is this ok use of system properties, with respect to the
on-going security work?
I don't think the SecurityManager is going to be the problem, the bigger
problem is that other code can clear those properties or change the
complete system set.
Dan.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
