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] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Date Thu, 03 Aug 2006 16:20:11 GMT

Rick Hillegas (JIRA) wrote:
>      [ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
> Rick Hillegas updated DERBY-700:
> --------------------------------
>     Fix Version/s:
>                        (was:
> It appears that fixing this bug will require us to agree on some mechanism for caching
VM-global Derby state. This seems to be an architectural decision which requires careful thought
and experiment. I think we should defer this to a future release. I am moving this to 10.3
because thatt's the next release available in the dropdown. I agree with Kathey that this
is a good candidate for a bug fix release in the 10.2 lineage.
If anyone has ideas on this one, please post them.  I have been stumped 
by this one so far.  As I posted earlier I think one approach simply
needs a way to uniquely identify the current JVM, and also some way
to coordinate a sync block across 2 class loaders.  So far I have
been convinced by dan and david that using System properties is the
wrong approach.

As kathy has said the consequences of this is that
user may corrupt the db so it is bad.  We should document either in
release notes or the main documentation that Derby does not currently
support accessing the same db, in the same JVM, from 2 separate class 
loaders.  System properties in general are a problems for this 
configuration, and I believe we do no testing of the configuration
either.  Any opinions on where this info should show up.

As this is an unsupported configuration, I believe that it should not
hold up the 10.2 release, but  I also agree that whenever we get an 
agreed upon fix it should go into the next release of all current

View raw message