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 22:52:12 GMT
a complete solution is not available yet, but the current thought
is that we need some way to uniquely identify the JVM that the
class loader is running in.  One proposal is to have derby generate
such an ID, probably using some kind of UUID approach.  Then put
the ID into the system property so that both classloaders can see
it.  Suresh has pointed out there is probably some race condition
with this, if the 2 classloaders can't use any sort of java synchronization.

Once we have a unique ID, then we would use some standard kind of
file locking scheme from within both class loaders to see if a
class loader, from this JVM is working on the db I am opening.
The problem of preventing multiple JVM's works now and would
continue unchanged, we are exploring adding an extra step just
to catch the 2 classloaders from the same JVM's.

I would rather not use system properties, but haven't come up
with anything else yet.

If you have access to one of the mail archivers the interesting
exchanges are under the following subject:

Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot of 
database from different classloaders on Linux

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