Table of Contents

Class StoredProcedureRequestOptions

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

The cosmos stored procedure request options

public class StoredProcedureRequestOptions : RequestOptions
Inheritance
StoredProcedureRequestOptions
Inherited Members
Extension Methods

Constructors

StoredProcedureRequestOptions()

public StoredProcedureRequestOptions()

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.

EnableScriptLogging

Gets or sets the EnableScriptLogging for the current request in the Azure Cosmos DB service.

public bool EnableScriptLogging { get; set; }

Property Value

bool

Examples

To log, use the following in store procedure:

console.log("This is trace log");

Remarks

EnableScriptLogging is used to enable/disable logging in JavaScript stored procedures. By default script logging is disabled. The log can also be accessible in response header (x-ms-documentdb-script-log-results).

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 new write request to Azure Cosmos DB is assigned a new SessionToken. The DocumentClient will use this token internally with each read/query 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 DocumentClient 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 Microsoft.Azure.Documents.Client.ResourceResponse<TResource> 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.