db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: security manager implication of requiring one or multiple system properties?
Date Sat, 28 Jan 2006 23:49:35 GMT
Note that the problem we are trying to solve is multiple derby
instances from 2 classloaders accessing the same database at the
same time.  We are unlikely to ever allow this - as correct
direct access to the database requires sharing a lot of information
(page cache, lock tables, ...).

I am not happy with the system property approach - but best I could
come up with so far, and the thread describes the problems with current 
lock files.

I don't know much about what is and is not available from different
classloaders.  I think all that is needed is some way to generate a 
unique key which can be used to identify what jvm instance I am in.  The pid
of the jvm would work, but I don't think it is available from java.
Then each classloader in the jvm could use some sort of file lock to 
tell if another classloader in the same jvm existed.

Alternate solutions are welcome.

David W. Van Couvering wrote:
> 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.

View raw message