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:

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.
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.
Related concepts
Avoiding table scans of large tables
Avoiding compiling SQL statements