Resolution of external routine libraries and classes
The external routine library resolution is performed at the database instance level. In a database instance that contains multiple databases, external routine libraries of one database can be referenced with an EXTERNAL NAME clause of the CREATE statement in another database.
Instance level external routine resolution supports code re-use by allowing multiple routine definitions to be associated with a single library. When external routine libraries are not re-used in this way, and instead copies of the external routine library exist in the file system of the database server, library name conflicts can happen. This can specifically happen when there are multiple databases in a single instance and the routines in each database are associated with their own copies of libraries and classes of routine bodies. A conflict arises when the name of a library or class used by a routine in one database is identical to the name of a library or class used by a routine in another database (in the same instance).
To minimize the likelihood of this happening, it is recommended that a single copy of a routine library be stored in the instance level function directory (sqllib/function directory) and that the EXTERNAL clause of all of the routine definitions in each of the databases reference the unique library.
- For C, C++, COBOL, and ADO.NET routines:
- Library name conflicts can be minimized or resolved by:
- Storing the libraries with routine bodies in separate directories for each database.
- Creating the routines with an EXTERNAL NAME clause value that specifies the full path of the given library (instead of a relative path).
- For Java™ routines:
- Class name conflicts cannot be resolved by moving the class files in question into different directories, because the CLASSPATH environment variable is instance-wide. The first class encountered in the CLASSPATH is the one that is used. Therefore, if you have two different Java routines that reference a class with the same name, one of the routines will use the incorrect class. There are two possible solutions: either rename the affected classes, or create a separate instance for each database.