System management component exits provide overall services such as activity logging. Unlike business components such as agents or preparsers, management component exits can provide stateful services.

As standard exits, these exits receive their metadata in the normal manner, and also have available such services as tracing. The services are provided at the server level rather than at the message level; for example, traces are issued with origin as the manager rather than the message executor. The writing of exits in general and the use of common methods is discussed in Writing Business Components.

The exits are initialized via the init() method when the server starts, and are terminated via the term() method as the server shuts down. Although the server makes every effort to call the term() method, certain system failures can prevent this and so exits should not depend upon receiving a term() for correct operation.

Unlike business exits, management exits can run on any thread and must be fully reentrant. Developers are cautioned to avoid non-synchronized object variables and expectation of sequence. Likewise, thread-specific data cannot be used. Developers are guaranteed that the init() and term() calls are controlled by the server and are not subject to reentrancy issues.

Users are cautioned that exits should be reentrant. Although some synchronized blocks may be necessary, their use should be reduced. Synchronization can lock the server and have a disproportionate effect on system performance.

Any component exit needs to be included in an extension and registered with the system. Use the addExit() method, discussed in Installing Components. However, the standard reference is done.

The name of the jar file containing the extension that you build should begin with the letter 'I'. This is a simple filter used do avoid attempting to investigate non-extension jars, and thus improve loading time.

Developers are encouraged to make management components "self-healing." Failure should not prevent the system from running and the exit should attempt to recover from errors. For example, an exit that loses access to a data base might hold its data in memory or on a disk until the data base is recovered during a subsequent entry to the component.