I think pid's are unique at a given moment, so using the process id
might work if Java provides a way to get a PID of process.
But I am not so sure how to generate such a unique id store it in
system property/any where else without hitting classical race
condition problems. I don't think it is possible to TEST/SET a system
property in one instruction.
Assuming such a race condition is rare and it is ok if that case is
not handled correctly, System properties can not be set under
security manager without special permission, I wonder if users
typically give such permissions.
Mike : Why do we need two unique id's? I could not follow why one
needs check class loader ID part ? I thought db boot just need to
check if the lock that we are getting is not already acquired by the
JVM through some other class loader.
Thanks
-suresh
Mike Matrigali wrote:
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
