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 Thu, 31 May 2007 22:16:11 GMT
Yes, you are right - This is quite a corner case anyway and if it does
happen, proper action (such as removing the file physically) would have to
be done manually as in the case today (if running pre-1.4.2) which should
not be the case with 10.3 (if am not mistaken) - Hence, Derby will remove a
db lock file that has been kept around and recreate a new one the next time
it opens the DB _IF_ that one is not already locked....I suppose this would
apply there too...

On 5/31/07, Kathey Marsden <kmarsdenderby@sbcglobal.net> 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.
> Kathey

View raw message