Table of Contents

Class TransactionalBatchRequestOptions

Namespace
Microsoft.Azure.Cosmos
Assembly
Microsoft.Azure.Cosmos.Client.dll

Cosmos batch request options.

public class TransactionalBatchRequestOptions : RequestOptions
Inheritance
TransactionalBatchRequestOptions
Inherited Members
Extension Methods

Constructors

TransactionalBatchRequestOptions()

public TransactionalBatchRequestOptions()

Properties

ConsistencyLevel

Gets or sets the consistency level required for the request in the Azure Cosmos DB service.

public ConsistencyLevel? ConsistencyLevel { get; set; }

Property Value

ConsistencyLevel?

The consistency level required for the request.

Remarks

Azure Cosmos DB offers 5 different consistency levels. Strong, Bounded Staleness, Session, Consistent Prefix and Eventual - in order of strongest to weakest consistency. ConnectionPolicy

While this is set at a database account level, Azure Cosmos DB allows a developer to override the default consistency level for each individual request.

SessionToken

Gets or sets the token for use with session consistency in the Azure Cosmos DB service.

public string SessionToken { get; set; }

Property Value

string

The token for use with session consistency.

Remarks

One of the ConsistencyLevel for Azure Cosmos DB is Session. In fact, this is the default level applied to accounts.

When working with Session consistency, each batch request with write operation to Azure Cosmos DB is assigned a new SessionToken. The CosmosClient will use this token internally with each read/query/batch request to ensure that the set consistency level is maintained.

In some scenarios you need to manage this Session yourself; Consider a web application with multiple nodes, each node will have its own instance of CosmosClient If you wanted these nodes to participate in the same session (to be able read your own writes consistently across web tiers) you would have to send the SessionToken from TransactionalBatchResponse of the write action on one node to the client tier, using a cookie or some other mechanism, and have that token flow back to the web tier for subsequent reads. If you are using a round-robin load balancer which does not maintain session affinity between requests, such as the Azure Load Balancer, the read could potentially land on a different node to the write request, where the session was created.

If you do not flow the Azure Cosmos DB SessionToken across as described above you could end up with inconsistent read results for a period of time.

https://docs.microsoft.com/azure/cosmos-db/consistency-levels