Unload a shared-object file
In an attempt to keep memory usage to a minimum, the routine manager attempts to unload a shared-object file when it finds that no one is using any of its UDRs. That is, it unloads a shared-object file when all references to the UDRs within the shared-object file are removed from the internal cache of the database server and any one of them is marked as being dropped.
- Explicitly drop a UDR
When you use the DROP FUNCTION, DROP PROCEDURE, or DROP ROUTINE to drop all UDRs in a shared-object file, the routine manager unloads the shared-object file.
- Explicitly drop a database
The routine manager unloads all shared-object files when DROP DATABASE executes.
- Create and reference UDRs in a transaction
BEGIN WORK;
CREATE FUNCTION c_func() ...;
CREATE FUNCTION spl_func() RETURNING c_func()...;
COMMIT WORK;
- For each routine that references the shared object (external file),
execute the following SQL statement
ALTER ROUTINE routine-name (args, ...) WITH ( MODIFY EXTERNAL NAME = 'shared-obj' );
The new pathname for the shared object must be different from the existing one for the shared object to be unloaded. Instead of ROUTINE, you can specify FUNCTION for a function or PROCEDURE for a procedure.
After the last routine is altered, nothing in the database server will refer to the old shared object, and a message appears in the online log to report that the shared object has been unloaded.
- Drop all UDRs in the shared-object file
When you execute DROP FUNCTION, DROP PROCEDURE, or DROP ROUTINE to drop all UDRs in a shared-object file, the routine manager unloads the shared-object file. Similarly, the routine manager unloads all shared-object files when DROP DATABASE executes. Execution of one of these SQL statements is the safest way to unload a shared-object file.
- Execute the SQL procedure, ifx_unload_module(), to request
that an unused shared-object file be unloaded
The ifx_unload_module() function can only unload an unused shared-object file; that is when no executing SQL statements (in any database) are using any UDRs in the specified shared-object file. If any UDR in the shared-object file is currently in use, ifx_unload_module() raises an error.
- Load a new module of a different name with the SQL function ifx_replace_module()
With the ifx_replace_module() function, you do not have to change all the routine definitions. This action will eventually cause the old shared-object file to unload.
DataBlade modules can be shared across databases. Therefore, you might have more than one database using the same DataBlade module.
In Figure 1, the routine manager has loaded the shared-object file named source1.so. This shared-object file contains definitions for the user-defined functions func1(), func2(), and func3().
19:14:44 Unloading Module </usr/udrs/source1.so>
19:14:44 The C Language Module </usr/udrs/source1.so> unloaded
The message-log file is a useful place to check that the shared-object file is unloaded from the virtual processors. Alternatively, you can use the onstat -g dll command to monitor the results of an shared-object-file unload.
For information about when the shared-object file is loaded, see Load a shared-object file. For information about how to prevent a shared-object file from being unloaded, see Lock a shared-object file in memory.