WebSphere Message Brokers
File: as01460_
Writer: Lorraine Waitt

Concept topic

This build: July 31, 2007 21:36:59

Threading

Message processing nodes and parsers must work in a multi-instance, multithreaded environment. Many node objects or parser objects are available, each with several syntax elements, and many threads can be executing methods on these objects.

An instance of a message flow processing node is shared and used by all the threads that service the message flow in which the node is defined. An instance of a user-defined parser is used only by a single message flow thread.

A user-defined extension must use this model. If a user-defined node requires global data or resources, then you must protect the global data or resources by using semaphores to serialize access across threads. However, such serialization can result in performance bottlenecks. Avoid using global data and resources to create a more scalable solution.

The functions implemented by user-defined extensions must be reentrant, and any functions that they invoke must also be reentrant. All user-defined extension utility functions are fully reentrant.

Although a user-defined extension can create additional threads if required, you must return control to the broker on completion of an implementation function. If you do not do so, your code might compromise the integrity of the broker and cause unpredictable behavior.

Related concepts
User-defined input nodes
Execution model
Related tasks
Creating an input node in C
Extending the capability of a C input node
Creating an input node in Java
Related reference
cniDispatchThread
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:36:59

as01460_ This topic's URL is: