Dynamic Changes to Jar Files or Database Jar Class Path

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 "class path" dynamically (without having to reboot).

That is, when you install or replace a jar file within an SQL statement or change the database jar "class path" (the derby.database.classpath property), Derby is able to load the new classes right away without your having to reboot.

Certain conditions must be met for this to be true:

• 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.

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 class path 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.