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
- Re: [jira] Updated: (DERBY-700) Derby does not p... Kathey Marsden
-
