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.
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
- For read-only applications, use table-level locking and the READ_COMMITTED
- Boot databases at startup to minimize the impact of connecting.
Tuning tips for single-user systems
- 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.