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 <[EMAIL PROTECTED]> 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
