Noel J. Bergman wrote:
jta wrote:
...
2) Which jdbc driver is being used?
See our config file. The only entry is:
<driver>org.apache.derby.jdbc.EmbeddedDriver</driver>
I assume that answers the question, and that we are using the embedded
driver version of Derby. Should we be doing things differently?
That's fine. What it means is multiple connections to a given database
must be via the application that boots it.
I was interested in knowing which driver because there are some
memory-related jira issues opened against the network server / client
driver; for example, DERBY-210 and DERBY-550.
How do we
ensure that Derby gets shutdown cleanly, or at least can do what it needs to
do to ensure that the database does not get corrupted by some other program
failure?
When the embedded application exits, derby will be shut down.
You can also do a "clean shutdown", which will perform a checkpoint and
release resources. This does a clean shutdown for just database "foo":
DriverManager.getConnection("jdbc:derby:foo;shutdown=true");
This shuts down all databases that the application has booted and also
shuts derby down:
DriverManager.getConnection("jdbc:derby:;shutdown=true");
A clean shutdown always throws SQL exception XJ015, and this can be ignored.
If you don't cleanly shutdown a database, the next time the database is
started, Derby will run recovery on that database.
If you don't do a clean shutdown, nothing bad will happen; it just
causes a minor delay on the next startup.
Note that an application that connects using the network server and a
client jdbc driver shouldn't do a shutdown -- that could interfere with
other applications.
Dan, please correct me on any details here.
-jean
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
