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/[EMAIL
PROTECTED]
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
