db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
Subject Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Date Wed, 25 Jan 2006 07:59:59 GMT

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
>>
>>
>>
> 
> 


Mime
View raw message