Class StoredProcedureRequestOptions
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
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.