Creating Transacted Sessions
A client can create one or more transacted sessions within an existing session. A transacted session always has exactly one active transaction. Once a transacted session is created, a transaction automatically begins within that transacted session.
Within a transacted session, a client can create a maximum of one producer flow to publish messages (see Publishing Messages in Transactions) and a maximum of 256 consumer flows to consume messages (see Consuming Messages in Transactions).
Java RTO, C and .NET APIs
For the Java RTO, C, and .NET APIs, by default a transacted session automatically establishes a producer flow for a transacted session and lazily creates a context‑bound message dispatcher thread for asynchronous message delivery.
You can modify the default transacted session properties if:
- You do not want to allow publish operations in transactions.
- You want to use a new transacted-session-bound message dispatcher when asynchronously receiving messages rather than the default context-bound message dispatcher. (Using transacted‑session-bound message dispatcher threads can possibly improve performance, but they add programming and debugging complexity.)
- you want to change the timeout value (in milliseconds) to wait for response from the event broker when invoking transacted session operations such as commit or rollback.
The other transacted session property that you can modify is the amount of time (in milliseconds) to wait for a response from the event broker when invoking transacted session operations such as commit or rollback.
PubSub+ Messaging API | Use |
---|---|
Java RTO |
SessionHandle. |
C |
solClient_session_ |
.NET |
ISession.createTransactedSession(...) |