Rebuilding routine shared libraries

The database manager caches the shared libraries used for stored procedures and user-defined functions once loaded. If you are developing a routine, you might want to test loading the same shared library a number of times, and this caching can prevent you from picking up the latest version of a shared library. The way to avoid caching problems depends on the type of routine.

  1. Fenced, not threadsafe routines. The database manager configuration keyword keepfenced has a default value of YES. This keeps the fenced mode process alive. This default setting can interfere with reloading the library. It is best to change the value of this keyword to NO while developing fenced, not threadsafe routines, and then change it back to YES when you are ready to load the final version of your shared library. For more information, see Updating the database manager configuration parameters.

  2. Trusted or threadsafe routines. Except for SQL routines (including SQL procedures), the only way to ensure that an updated version of a routine library is picked up when that library is used for trusted, or threadsafe routines, is to recycle the database instance by entering db2stop followed by db2start on the command line. This is not needed for an SQL routine because when it is recreated, the compiler uses a new unique library name to prevent possible conflicts.

For routines other than SQL routines, you can also avoid caching problems by creating the new version of the routine with a differently named library (for example foo.a becomes foo.1.a), and then using either the ALTER PROCEDURE or ALTER FUNCTION SQL statement with the new library.