I haven't looked at the absolute latest changes and I was wondering if the case of a database being opened in a separate classloader and not having been shut down properly (due to unexpected exception in the application) could impede some other classloader to open the very same database due to the state of the dbex.lck file, not having been changed due to the exception in the other classloarder?
On 5/30/07, Kathey Marsden <[EMAIL PROTECTED]> wrote:
Daniel John Debrunner wrote: > Kathey Marsden wrote: >> Daniel John Debrunner wrote: >>> >>> Actually string constants are by definition interned, so >>> synchronized(DERBY_JVM_ID) is the same as >>> synchronized(DERBY_JVM_ID.intern()) since DERBY_JVM_ID is a >>> reference to a string constant. Though using intern() wouldn't harm >>> and might make the code more readable. >>> >> Silly question. Would an interned string allow synchronization >> across classloaders? >> If not, how do I synchronize two threads using different classloaders. >> Kathey > > Yes. The intern() provides a reference that will be identical > regardless of any current class loader because the String class will > only be loaded once by the jvm. You can google for other folks using > the same trick, or using other objects that are guaranteed to be > loaded once such as Integer.class, Integer.TYPE etc. > So I will assume then that my problem is 2) Since getting the exFileLock is not within the synchronized code. It is possible that the state of the dbex.lck file on disk changes before the boot. I'll approach it from that angle. Kathey
