Synchronous event emission is not supported for system capture points therefore emission of system events cannot be assured.
Synchronous events can be transactional or non-transaction but the recoverability of the transport must be set up correctly in each case.
Not all EP adapters can support synchronous emission with all combination's of TRANSMODE. For more information, see Event processing adapters.
When an event fails to be emitted, the EP adapter provides information about the event and why it was not emitted, increments relevant event statistics, and causes the unit of work for the capturing transaction to be backed out.
Understanding the way that synchronous event emission works helps you to understand how to make the best use of this capability. Some things to consider when you use synchronous event emission include: security, performance, transport, and effects on applications.
The event-capturing transaction must have write authority to the event emission transport (for example, the WebSphere® MQ queue for the WebSphere MQ EP adapter) for synchronous emissions; the EP dispatcher or adapter task that emits events needs write authority for asynchronous emission.
Synchronous, transactional event emission is recoverable. When you use the CICS WebSphere MQ EP adapter, events are put on the WebSphere MQ event queue under sync point; therefore, you might have to review your WebSphere MQ log data set space allocation. When you use the CICS TSQ EP adapter, this adapter increases the use of your recoverable TS queue so you might have to review your CICS log stream size and attributes. Using synchronous transactional events with a task that runs for a long time without taking a sync point can cause the log to overflow.
When using synchronous emission, a custom EP adapter must honor the EPAP_RECOVER flag in the DFHEP.ADAPTPARM container. For more information, see Custom EP adapter.
Assuring your event emission provides the opportunity to build business critical event-based applications, and extend existing applications in a reliable way. The trade-off is that the synchronous processing that is essential to assuring that events are emitted might have an impact on your application response time. A judicious use of synchronous event emission minimizes the application impact. See Event processing performance for more information about performance considerations when assuring event emission.
A single unit of work might cause many events to be emitted, where some events are transactional and some events are non-transactional. If a capturing transaction fails to emit a synchronous event, the unit of work is backed out with any transactional events that it captures. Non-transactional events might still be emitted.
The EP adapter, its resources (such as a WebSphere MQ queue), and the event consumer must be configured with enough capacity to process the expected peak volume of events to be emitted in order to prevent the capturing transaction from failing.
To help you decide where to use synchronous emission, here are some considerations for asynchronous and synchronous emission for comparison: