Hi Tom,
The database shutdown attempt, by the second application, should simply
raise an exception. It should not crash the database and cause recovery
problems later on. That, at least, is how Derby is supposed to operate
and I'm not aware of a bug in this area. However, if you can demonstrate
such a bug, I am sure it will be regarded as a high priority issue and
probably a blocker for the next release.
Regards,
-Rick
tom_ wrote:
Yes, I agree, it doesn't need to and should not try a shutdown, and that's
how the application's logic works. I have just found out that another
application by whatever reasons tries to make a shutdown in the described
situation. I wonder if this trial could result in a database crash -
eventually afterwards when the other application does the shutdown. It would
explain why I am observing the recovery problem so often.
Rick Hillegas-2 wrote:
Hi Tom,
The database is successfully booted in only one VM and can be shut down
only in that VM. The second application, running in a different VM, can
not get a connection to the database and can not shut down the database,
either. The second application should abandon its trial and not attempt
a shutdown.
Hope this helps,
-Rick
tom_ wrote:
I have a question, if a program tries to access a database that is
already
opened by another one, how should the program proceed, should it just
stop
the trial without trying a shutdown of the database or try a shutdown? If
it
would try a shutdown could this affect the state of the database?
oysteing wrote:
tom_ wrote:
Without having a crash or something like that before, when trying to
reopen
the database the error message is "Failed to start database". Is there
a
possibility to start the database again?
Just one more comment here: Make sure to explicitly shut down your
database before exiting your application? If it is shut down properly,
the database should not go into recovery at start-up. (I guess this
will not solve your problem since your database will still be vulnerable
to crashes until this bug is fixed, but normal startup will be quicker
if you avoid recovery)
--
Øystein
