db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Date Tue, 24 Jan 2006 20:11:45 GMT
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

o the monitor also creates a unique id for it's existence in the

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

View raw message