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
JVM.
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
