-
-
Notifications
You must be signed in to change notification settings - Fork 364
Transaction context
When Rebus receives messages, it does this by establishing a transaction context (something that implements ITransactionContext
), which is then used throughout handling the message to perform actions in the right order.
It can be boiled down to wanting to support at least once delivery, which means that Rebus must never delete a message from a queue before it has been fully handled.
This can be achieved by always performing tasks in the right order:
- Receive message
- Do work(*)
- Delete message
and then just not perform step 3 if step 2 fails.
The transaction context helps you do that :)
The first thing you can do, is to use the transaction context to stash things that you want to have access to thoughout your message handler and the logic that it carries out.
You will then usually set up your IoC container to resolve things by creating them on the first request, stashing them in the transcation context, and then resolving them from there on any subsequent requests within the same message handler.
The transcation context is capable of having actions enlisted in it, which will then be executed at the right time. You will probably use this mechanism to commit your work if it was successfully completed.
The transaction context is available everywhere it makes sense :)
If you're in a message handler, you can have an IMessageContext
injected and use its TransactionContext
property.
If you're in the [incoming messages pipeline|Incoming messages pipeline], you can use the [incoming step context|Incoming step context] to Load<ITransactionContext>()
.
Even if you don't have access to these things, you can still get to the transaction context via AmbientTransactionContext.Current
, which is a logically thread-bound instance (i.e. it "flows" properly across continuations)
If you're interested in seeing a full example on how the transaction context can be used to implement a proper unit of work, please check out the Unit of work page.
Basic stuff
- Home
- Introduction
- Getting started
- Different bus modes
- How does rebus compare to other .net service buses?
- 3rd party extensions
- Rebus versions
Configuration
Scenarios
Areas
- Logging
- Routing
- Serialization
- Pub sub messaging
- Process managers
- Message context
- Data bus
- Correlation ids
- Container adapters
- Automatic retries and error handling
- Message dispatch
- Thread safety and instance policies
- Timeouts
- Timeout manager
- Transactions
- Delivery guarantees
- Idempotence
- Unit of work
- Workers and parallelism
- Wire level format of messages
- Handler pipeline
- Polymorphic message dispatch
- Persistence ignorance
- Saga parallelism
- Transport message forwarding
- Testing
- Outbox
- Startup/shutdown
Transports (not a full list)
Customization
- Extensibility
- Auto flowing user context extensibility example
- Back off strategy
- Message compression and encryption
- Fail fast on certain exception types
Pipelines
- Log message pipelines
- Incoming messages pipeline
- Incoming step context
- Outgoing messages pipeline
- Outgoing step context
Prominent application services