The current storage transaction is exposed via the SynchronizedStorageSession
property on the IMessageHandlerContext
implementation. The transaction can be used to ensure atomicity of operations performed by both the business logic and the persister. When running endpoints with the Outbox feature turned on; the same transaction will be used for any outgoing messages as well.
Using in a Handler
public class HandlerThatUsesSession : IHandleMessages<Message>
{
public async Task Handle(Message message, IMessageHandlerContext context)
{
var session = context.SynchronizedStorageSession.ServiceFabricSession();
var stateManager = session.StateManager;
var transaction = session.Transaction;
var dictionary = await stateManager.GetOrAddAsync<IReliableDictionary<string, string>>(transaction, "state");
await dictionary.AddOrUpdateAsync(transaction, "key", _ => "value", (_, __) => "value");
}
}
Using in a Saga
Other than interacting with its own internal state, a saga should not access a database, call out to web services, or access other resources. See Accessing databases and other resources from a saga.
If the situation is special enough to warrant going against this recommendation, the following documentation will describe how to do so.
public class SagaThatUsesSession : Saga<SagaThatUsesSession.SagaData>,
IHandleMessages<Message>
{
public async Task Handle(Message message, IMessageHandlerContext context)
{
var session = context.SynchronizedStorageSession.ServiceFabricSession();
var stateManager = session.StateManager;
var transaction = session.Transaction;
var dictionary = await stateManager.GetOrAddAsync<IReliableDictionary<string, string>>(transaction, "state");
await dictionary.AddOrUpdateAsync(transaction, "key", _ => "value", (_, __) => "value");
}
Shared transaction should not be committed (CommitAsync()
) or disposed (Dispose()
) in the handler or the saga.
Using a custom transaction
When the data needs to be persisted in a custom collection during the handler or saga execution, the action should not participate in the provided transaction. Instead, a new transaction should be created using the StateManager
property of the incoming session. This is useful when the information needs to be stored regardless of the outcome of the handler's execution.
Service Fabric transactions should be as short-lived as possible and touch only a single resource to reduce lock contention and avoid timeouts.
public async Task Handle(Message message, IMessageHandlerContext context)
{
var session = context.SynchronizedStorageSession.ServiceFabricSession();
var stateManager = session.StateManager;
using (var transaction = stateManager.CreateTransaction())
{
var dictionary = await stateManager.GetOrAddAsync<IReliableDictionary<string, string>>(transaction, "specialCollection");
await dictionary.AddOrUpdateAsync(transaction, "key", _ => "value", (_, __) => "value");
await transaction.CommitAsync();
}
}