Transactional Client

Pattern Catalog

Previous Previous   Next Next

Site Home • Patterns Home • Table of Contents

A messaging system, by necessity, uses transactional behavior internally. It may be useful for an external client to be able to control the scope of the transactions that impact its behavior.

How can a client control its transactions with the messaging system?

Use a Transactional Client—make the client’s session with the messaging system transactional so that the client can specify transaction boundaries.

Both a sender and a receiver can be transactional. With a sender, the message isn’t “really” added to the channel until the sender commits the transaction. With a receiver, the message isn’t “really” removed from the channel until the receiver commits the transaction. A sender that uses explicit transactions can be used with a receiver that uses implicit transactions, and vise versa. A single channel might have a combination of implicitly and explicitly transactional senders; it could also have a combination of receivers.

...

Related patterns: Channel Adapter, Competing Consumers, Document Message, Event-Driven Consumer, Event Message, Guaranteed Delivery, Message, Message Channel, Message Dispatcher, Message Endpoint, Message Router, Message Sequence, Message Translator, Messaging Bridge, Pipes and Filters, Point-to-Point Channel, Polling Consumer, Publish-Subscribe Channel, Request-Reply, Resequencer


Discuss this pattern on the Wiki. The Wiki allows you to add comments / suggestions for each pattern and even to add new pages. Simply follow this link and click "Edit" at the bottom of the window.   [How to use a Wiki.]  [EAI Patterns Wiki Home Page]

For a full description of the pattern see:

Enterprise Integration PatternsEnterprise Integration Patterns
Gregor Hohpe and Bobby Woolf
ISBN 0321200683
650 pages
Addison-Wesley


Home • Patterns • Table of ContentsPrevious Previous   Next Next