Shutting down the system

In an embedded environment, when an application shuts down, it should first shut down Derby.

If the application that started the embedded Derby quits but leaves the Java Virtual Machine (JVM) running, Derby continues to run and is available for database connections.

In an embedded system, the application shuts down the Derby system by issuing the following JDBC call:


Shutdown commands always raise SQLExceptions.

When a Derby system shuts down, a message goes to the log file:

Thu Sep 13 09:53:21 EDT 2012: Shutting down Derby engine
Thu Sep 13 09:53:21 EDT 2012:
Shutting down instance a816c00e-0139-bfe6-bff8-000000a155b8 on 
database directory C:\sampledb with class loader 

If you are running with a security manager, you must grant Derby permission to deregister the embedded driver in order to fully shut down the system. See "Configuring Java security" in the Derby Security Guide for details.

Typically, an application using an embedded Derby engine shuts down Derby just before shutting itself down. However, an application can shut down Derby and later restart it in the same JVM session. To restart Derby successfully, the application needs to reload org.apache.derby.jdbc.EmbeddedDriver explicitly, as follows:


This is an exception to the rule that you do not need to load the driver explicitly when starting Derby.

The JDBC specification does not recommend calling newInstance(), but adding a newInstance() call guarantees that Derby will be booted on any JVM.

Note: If your application will need to restart Derby, you can add the attribute deregister=false to the connection URL to avoid having to reload the embedded driver:

It is also possible to shut down a single database instead of the entire Derby system. See Shutting down Derby or an individual database. You can reboot a database in the same Derby session after shutting it down.

Related concepts
Booting databases