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.
