Dynamic changes to jar files
Derby Developer's Guide
46
You load resources the way you normally would, using the standard
java.lang.Class.getResourceAsStream, a mechanism that allows an application to access
resources defined in the classpath without knowing where or how they are stored.
You do not need to make any changes to the way code interacts with Derby and its JDBC
driver. An application can safely attempt to boot Derby, even though it is already running,
without any errors. Applications connect to Derby in the usual manner.
Note: The method getResource is not supported.
Dynamic changes to jar files or to the database jar classpath
When you store jar files in a single database and make those jar files available to that
database, it is possible to make changes to jar files or to change the database jar
"classpath" dynamically (without having to reboot).
That is, when you install or replace a jar file within an SQL statement or change the
database jar "classpath" (the derby.database.classpath property
),
Derby is able to load
the new classes right away without your having to reboot.
Requirements for dynamic changes
Certain conditions must be met for Derby to be able to load the new classes right away
without you having to reboot.
· You originally configured database-level class loading for the database correctly.
Turning on the database-level class loading property requires setting the
derby.database.classpath property with valid two-part names, then rebooting.
· If changes to the derby.database.classpath property are needed to reflect new jar
files, you change the property to a valid value.
If these requirements are not met, you will have to reboot to see the changes.
Notes on dynamic changes
When you are changing the derby.database.classpath property, all classes loaded from
database jar files are reloaded, even for a jar file that has not changed.
Remember that the user's classpath is searched first.
Any existing prepared statements will use the previously loaded classes unless they
require class loading, in which case they will fail with a ClassNotFound error.
Cached objects do not match objects created with newly loaded classes. For example, an
in-memory Customer object will not match a new Customer object if the Customer class
has been reloaded, and it will raise a ClassCastException.
