db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini" <francois.ors...@gmail.com>
Subject Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Date Wed, 30 May 2007 21:27:59 GMT
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 <kmarsdenderby@sbcglobal.net> 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
>
>

Mime
View raw message