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, 31 May 2007 18:28:52 GMT

Kathey Marsden wrote:
> Kathey Marsden wrote:
>> Francois Orsini wrote:
>>> 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?
>> I think this is a legitimate concern  (assuming I can get the thing 
>> working to prevent dual boot) as the System property and file contents 
>> would still match.  I'm not quite sure how to ensure proper cleanup in 
>> this case.  There once was a request that we have an option that the 
>> database shutdown if there were no connections.  That's about the only 
>> way I can see to resolve it.
> Well the good news is I got the synchronization working.  On the cleanup 
> issue, I have been thinking about this case and I think that typically 
> an App Server is going to have one classloader per JDBC Provider.  For 
> example they might have two versions of Derby with different 
> classloaders accessing two different databases.  Typically if the 
> application is restarted it would be in the same Classloader I think.  
> Normal usage would not be to have two different Classloaders accessing 
> the same database.  For that network server would make more sense.

I think the key is to outline the intended environments Derby is meant 
to support/run well in.  DERBY-700 goal is to prevent corruption in a
case where Derby is not meant to run - just as Derby already has support
for preventing access from multiple JVMs, it's goal is not to encourage
users to use Embedded Derby in mulitple classloaders against the same

Embedded Derby is intended to be run where access to a single derby 
database is always intended to be from a single class loader from a 
single JVM.  In order to provide correct locking and expected database
caching performance Embedded Derby uses memory that must be directly
accessible to all threads accessing the database.  The current
implementation of Embedded Derby can only support this when accesses
are always channeled to a single classloader within a single JVM.

Network Derby is intended to be run in all other cases:
multiple machines:  The obvious case is accessing a single derby
                     database from separate machines
multiple JVMs:      The slightly less obvious is accessing derby from
                     separate JVM's on same machine.
multiple classloaders within same JVM:
                     And unfornately not obvious at all is that it is
                     required to access a single derby database started
                     in one classloader in a JVM from any any other
                     classloader in the JVM.

Note all these restrictions are about running Derby against a given 
database.  There are no restrictions about running 2 different
  databases in 2 different class loaders, and these Derby instances
can be different versions of the Derby software.

> Kathey

View raw message