For the generic 2 JVM problem we considered a process id scheme, but gave up when we could not find encough pure java support. There are actually 2 issues: 1) enforce the lock 2) determine if the existing lock is false, ie. the creating process exited without cleaning up the lock file.
Until jdk1.4.2 and file locking we suffered from not being able to reliably implement #2. We had 2 options, either assume the lock file was valid and force someone to clean up the lock file or go ahead and boot while logging an error message. Because it was so easy to leave the lock file around we did the error message approach. There was a property users could enable to force a hard error if the lock file was around. So the process id approach needs the following jvm support, if using the traditional lock file approach: 1) some way to uniquely identify a running JVM instance 2) some way to identify if that JVM is running We are looking for a pure java solution. I just checked the java 1.4.2 System interface and no portable solution jumped out at me. But having said that, maybe the dual class loader issue can be treated as a secondary locking issue - an additional lock requested before the existing cross process locking scheme (which does work, pure java across all jvm's >= 1.4.2). I think rather than process id we may just need to figure out if 2 class loaders from the SAME jvm are trying to access the file. This may be an easier problem to solve. I think there is some solution to be had using system properties to share information across the class loaders. Maybe something like: o the monitor sets a system property to a UUID which uniquely identifies the JVM it is running in. If the property exists already no work is done. o the monitor also creates a unique id for it's existence in the classloader. o db boot now checks the uuid.dat file in the db directory and sees if the lock is owned by anyone, and if so is it owned by this classloader as identified by the monitor unique id. o Question is how to tell if the existing lock file has been falsely left around by an exited class loader? I assume there is no way to ask the JVM if classloader X exists. Can we just count on monitor code to do the right thing with the lock file in most cases and in the case of JVM failure we won't be looking at that lock file anyway? Bryan Pendleton wrote: > Suresh Thalamati wrote: > >> Any ideas to fix this problem ? > > > What if you included some additional information in the lock files, > and then changed the locking algorithm so that it considered more > than just the presence or absence of the lock file, and whether it > could be locked successfully or not. > > For example, in traditional Unix programming, one would put the > process ID of the process which was locking the thing into the file, > either in the contents of the file or in the name of the file. > > That way, another process which came along and discovered the lock > file could know not only that some other process was trying to lock > the object, but also the process ID of that process. > > To adapt this algorithm to your case, you would need some sort of > unique identifier for each class loader. Then, class loader A in the > VM would encounter the lock file, and would see that class loader B > in that VM had created the lock file, and would know that the database > was locked and a lock error should be returned. > > In pseudocode: > > if (file exists && > I am able to lock the file && > (the file was written by a different process || > the file was written by a different class-loader)) > then > the database is locked, return lock error > > Does this work? > > thanks, > > bryan > > >
