db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: security manager implication of requiring one or multiple system properties?
Date Mon, 30 Jan 2006 19:05:33 GMT
FYI, I found this interesting blog.

http://www.jroller.com/page/oburn/20041005

I had discovered UID too, but it didn't seem to quite cover it.  I am 
wondering what he means by a "JVM property", but further searching makes 
me think this is an IBM VM/Websphere-specific feature...

David

Daniel John Debrunner wrote:
> Daniel John Debrunner wrote:
> 
> 
>>Mike Matrigali wrote:
>>
>>
>>
>>>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.
>>
>>
>>I guess I'm not seeing the jump from unique jvm id to use of a file
>>lock. If a file lock doesn't prevent multiple threads within a JVM from
>>modifying a file, how does the unique jvm id help?
> 
> 
> Sorry, found the discussion of the possible algorithm at
> 
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200601.mbox/%3c43D68A01.5050806@sbcglobal.net%3e
> 
> Dan.
> 

Mime
View raw message