Shielding users from Derby class-loading events

JVMs tend to load classes as they are needed, which means the first time you need a class in a piece of software, it takes longer to use.

Derby has three clear cases when a lot of class loading occurs:

When the system boots
The system boots when you load the embedded driver, org.apache.derby.jdbc.EmbeddedDriver. In a server framework, the system boots when you start the server framework. Booting Derby loads basic Derby classes.
When the first database boots
Booting the first database loads some more Derby classes. The default behavior is that the first database boots when the first connection is made to it. You can also configure the system to boot databases at startup. Depending on your application, one or the other might be preferable.
When you compile the first query
Compiling the first query loads additional classes.

For any of these events, you can control the impact they have on users by starting them in separate threads while other tasks are occurring.

In addition, if you are using PreparedStatements, prepare them in a separate thread in the background while other tasks are occurring.

Tuning tips for multi-user systems

For concurrency, use row-level locking and the READ_COMMITTED isolation level.
For read-only applications, use table-level locking and the READ_COMMITTED isolation level.
Boot databases at startup to minimize the impact of connecting.

Derby boots when you first load the embedded JDBC driver (org.apache.derby.jdbc.EmbeddedDriver). Load this driver during the least time-sensitive portion of your program, such as when it is booting or when you are waiting for user input. For server frameworks, the driver is loaded automatically when the server boots.
Boot the database at connection (the default behavior), not at startup. Connect in a background thread if possible.
Turn off row-level locking and use READ_COMMITTED isolation level.