Thread Safety

The PubSub+ messaging APIs ensure that certain API elements are thread-safe, while others are the responsibility of the application developer. The table below lists who is responsible for the thread safety of each API element:

 

Element of PubSub+ APIs	Thread Safety
	API Built-In Thread Safety	Application Developer's Responsibility
Contexts
Sessions
Flows
Messages
Transacted Sessions
Transacted Flows

Contexts, Sessions, and Flows: Thread Safe

Your enterprise might need multiple contexts to organize communications between applications and event brokers. Similarly, your applications might use multiple publishers or receivers in a single session, requiring multiple threads. To ensure that your applications can rely on determinate API results during operation, the messaging APIs guarantee that all contexts, sessions, and flows you create are thread safe. The messaging APIs use two built-in mechanisms to ensure that contexts, sessions, and flows, which allow for guaranteed messaging, remain thread-safe:

 

All callbacks in the PubSub+ messaging APIs occur on the same internal context thread, making them thread-safe.

Mutex (Mutual Exclusion)

To ensure thread safety, the messaging APIs use mutexes to limit a segment of code to a single thread. After that thread has executed that segment, the code segment is unlocked, and another thread can gain access to it. The use of mutexes ensures that only one thread at a time has access to resources that are shared by multiple threads.

Serialization

Sometimes thread safety can be required over many hundreds or thousands of lines of code. To avoid locking down large segments of code, which can cause programs to block and become non-performant, the messaging APIs use serialization. With serialization, the tasks for a particular operation are scheduled on a thread such that they occur in a specific sequence and are prevented from running simultaneously. This ensures that these tasks run serially and cannot conflict with each other.

Because serialization occurs on the messaging API Context thread, you do not need to implement it in your application.

The combination of these two mechanisms ensures that no indeterminate results or unexpected behaviors arise when you use contexts, flows, and sessions in multi-threaded, enterprise applications.

Messages: Developer Responsibility

The messaging APIs do not guarantee that messages are thread safe; however, this has more to do with the nature of event streaming than with data stability. We recommend that you implement individual message processing on a single thread. This ensures that the payload of each message will not be subject to race conditions or thread-safety problems, which could result in indeterminate results.

Transacted Sessions and Transacted Flows: Developer Responsibility

All of the PubSub+ messaging APIs support local transactions only (with the exception of JMS which also supports distributed transactions), and because local transactions are modeled after JMS transactions, they follow JMS protocols. The JMS protocol requires that local transactions, which include transacted flows and transacted sessions, be handled by a single thread. This is because there is no definite start or end on a transacted session and the completion of a transaction requires a commit call. After a transaction is committed, it is deemed complete. At that point, the transaction messages are sent or received, and a new transaction begins. This means that all processing of a transacted session or flow must be processed and controlled by a single thread, operating in a similar fashion to message processing. Although this means that transacted sessions and transacted flows are technically not thread safe, they operate in a single-threaded fashion that does not pose any thread-safety risks.