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
loads basic
classes.
- When the first database boots
Booting the first database loads some more
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.
Tuning tips for single-user systems
- 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 the READ_COMMITTED isolation level.