db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@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 17:40:48 GMT
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.


View raw message