Storage management in user-defined nodes

Consider issues that relate to storage management when you develop user-defined extensions in the C programming language.

If you are developing user-defined extensions using the Java™ programming language, you can use standard Java string handling methods.

All memory that is allocated by a user-defined extension must be released by the user-defined extension. The construction of a node at run time causes the cniCreateNodeContext function to be invoked, which allows the user-defined extension to allocate node instance specific data areas to store a context. The address of the context is returned to the integration node, and is passed back from the integration node when an internal method causes a user-defined extension function to be invoked; thus, the C user-defined extension can locate and use the correct context for the function processing.

The integration node passes addresses of C++ objects to the user-defined extension, which are used as handles to be passed back on subsequent function calls. Your C user-defined extension must not manipulate or use these pointers in any way, for example, by trying to release storage using the free function. Such actions cause unpredictable behavior in the integration node.

The cniCreateNodeContext implementation function is invoked whenever the underlying node object has been constructed internally. It is called when an integration node is defined with a message flow that uses a user-defined node. This activity is not necessarily the same as creating (or reusing) a thread to execute a message flow instance that contains the node. The cniCreateNodeContext function is called only once, during the configuration of the message flow, regardless of how many threads are executing the message flow.

Similar considerations apply to user-defined parsers, and the corresponding implementation function cpiCreateContext.