Communication exit library development restrictions

Restrictions

C-linkage

The communication exit library must be written in C or C++ and linked with C-linkage. Header files that provide the prototypes, data structures that are required to implement the libraries, and error code definitions are provided only for C and C++. The function db2commexitInit must be declared extern "C" if the library is compiled as C++.

Signal handlers

The communication exit library must not install signal handlers or change the signal mask. Doing so interferes with the signal handlers of the database manager. Interfering with the database manager signal handlers might seriously interfere with the ability to report and recover from errors.

Exceptions

The communication exit library APIs must not throw C++ exceptions. Such exceptions can interfere with database manager error handling.

Thread-safe

The communication exit library functions must be thread-safe. The db2commexitInit and db2commexitTerm functions are the only APIs that are not required to be thread-safe.

Exit handlers

The communication exit library must not install exit handlers or pthread_atfork handlers. The use of exit handlers is not supported because the communication exit library is unloaded before the database manager process exits.

Fork/threads

The communication exit library must not call, fork, or create new threads. This situation can lead to undefined behavior such as traps in the database manager.

Library dependencies

On Linux® and UNIX, the communication exit library is loaded from a process that is setuid or setgid. It cannot rely on the LD_LIBRARY_PATH, SHLIB_PATH, or LIBPATH environment variables to find dependent libraries. Therefore, the library must not depend on more libraries, unless any dependent libraries are accessible through other methods, such as:

• The dependent libraries exist in /lib or /usr/lib.
• The directories in which dependent libraries are found are specified OS-wide (such as in the ld.so.conf file on Linux).
• Dependent libraries are specified in the RPATH in the library itself.

Symbol collisions

When possible, communication exit libraries might be compiled and linked with any available options that reduce the likelihood of symbol collisions. Such as, options that reduce unbound external symbolic references. For example, use of the -Bsymboliclinker option on HP and Linux can help prevent problems that are related to symbol collisions. However, for libraries that are written on AIX®, do not use the -brtl linker option explicitly or implicitly.

32-bit versus 64-bit considerations

The database manager has both 32-bit and 64-bit versions, depending on the operating system. A 32-bit communication exit library must be enabled on a 32-bit database manager. A 64-bit communication exit library must be enabled on a 64-bit database manager. You cannot mix the two.

Stored procedures, triggers, and other internal SQL

Stored procedure interaction with the server is passed onto the communication exit library. Much of the interaction does not occur over standard communication channels and does not fit the model that is used for the exit library. Similarly, triggers, and other sources of internal SQL do not pass over standard communication channels and are not passed onto the communication exit library.

Communication buffers must not be manipulated

It is expected that the communication exit library does not manipulate or change the buffers that it is passed.

Rolling updates support

Db2® supports updating the fix pack level of individual members in Db2 pureScale® environments without stopping other members. This operation is known as rolling updates. Similarly, it is possible to update the level of the library that is used on individual members. It is possible that two different versions of the communication exit library might be running simultaneously on two different members. Similarly, each member can be at a different fix pack level. The communication exit library must tolerate such conditions without error.

Loading plug-in libraries on AIX with an extension of .a or .so

On AIX, security plug-in libraries can have a file name extension of .a or .so. The mechanism that is used to load the plug-in library depends on which extension is used:

• Plug-in libraries with a file name extension of .a

  Plug-in libraries with file name extensions of .a are assumed to be archives which contain shared object members. These members must be named shr.o for 32-bit or shr64.o for 64-bit. A single archive can contain both the 32-bit and 64-bit members, allowing it to be deployed on both types of operating systems.

• Plug-in libraries with a file name extension of .so

  Plug-in libraries with file name extensions of .so are assumed to be dynamically loadable shared objects. Such an object is 32-bit or 64-bit depending on the compiler and linker options that are used when it was built.

On all operating systems, other than AIX, security plug-in libraries are always assumed to be dynamically loadable shared objects.