Transactional Channel
The channel that knows how to say "commit together or rollback together" — topological alias of Transactional Client.
Problem
Sending a message after a DB write (or vice versa) without transactional coupling risks inconsistency: message sent but DB not committed, or DB committed but message lost.
Forces
- Send and write operations touch two distinct resources (broker + DB).
- XA two-phase commit is heavy and unavailable on many modern brokers (Kafka).
- The Outbox pattern provides a pragmatic alternative but needs a poller.
- A lost message can break the EDI partner chain.
Solution
The Transactional Channel pattern materialises in two forms: (1) an XA-compliant broker (IBM MQ, ActiveMQ with JTA); (2) the Outbox pattern — instead of sending to the broker, the producer inserts the message into an `outbox` table within the same DB transaction; a dedicated poller reads the table and publishes to the broker with broker-side idempotency. The latter is dominant in modern cloud-native (Kafka, SQS), the former is still used on enterprise EDI hubs.
EDI implementation
In EDI, a classic case: the ERP records a customer order and must publish an EDIFACT ORDERS to the supplier partner. Without Transactional Channel, the order persists but the ORDERS may be lost. Implementations: (a) IBM Sterling on DB2 with XA — high ops cost but no poller needed; (b) Outbox table on PostgreSQL + Debezium → Kafka → AS2 sender — modern pattern, low coupling. The pattern pays crucially in bug-after-incident scenarios where inconsistency persisted until manual fix.
Anti-patterns
- Send outside the transaction — guaranteed inconsistency in case of crash between both operations.
- XA for a non-XA broker (Kafka) — illusion of transaction that does not hold.
- Outbox without an idempotent poller — every retry duplicates the message on the broker.
- Pattern on both sides (XA + Outbox) — overengineering.
Related patterns
- Transactional Client — code-side view of the same guarantee.
- Guaranteed Delivery — complementary broker principle.
- Idempotency — avoids duplicates on the receiver side.
Sources
- Hohpe G., Woolf B. — EIP, Transactional Client (alias Transactional Channel). www.enterpriseintegrationpatterns.com/patterns/messaging/TransactionalClient.html
- Microsoft — Outbox pattern. learn.microsoft.com/en-us/azure/architecture/patterns/outbox