Comments (7)
Thanks for the feedback @blankor1.
Can you please explain in which scenario would the consistency be changed and the application not restarted?
If you are changing from Strong to Session, you need changes in the application, the same when going from Session to Strong or Bounded Staleness.
Going from Strong to Bounded Staleness also might require code changes.
In all cases, for the changes to be deployed, you need to restart the application.
from azure-cosmos-dotnet-v3.
Change Bounded Staleness to Strong, to guarantee all region Read Your Write
Strong and Bounded don't have differences on the write path but they do on the read path. When reading Strong, the read is a read that is already committed in all regions. Bounded Staleness is not, there is a staleness window. So your application needs to address this potential scenario somehow. You could attempt to read a document and the document might not exist or receive a stale version. So you presumably had code around these expectations. In Strong, this should not happen and if you get a 404, then that document doesn't exist. The code receiving this cannot be the same?
Change Session to Strong, to guarantee all region Read Your Writ
For Session, you need to have sticky routing or passing the session token somehow or maintaining it for the user. If there is no Session Token (maybe the user did not do a Write yet), you could get 404s/old data because then the consistency is Eventual. All that code is not needed for Strong and should be removed?
Degrade the consistency level back after temporarily increase the Consistency level.
Not sure I understand this scenario. You mean flipping the consistency temporarily? But during that time, whatever it is, unless you change the code (like any of the previous examples), your app might be broken? If you want to downgrade consistency as an opt-in, you can do it at the request level through the RequestOptions.
from azure-cosmos-dotnet-v3.
I just notices that this behavior is documented...
Then, I would like to make this as a feature requests. I see a feature request that is related to this case: #2117
Thanks!
from azure-cosmos-dotnet-v3.
For us, in many cases, this feature is to make it more convenient to use the SDK. Through my understanding, only changing consistency level to involving Session and also respect session token will need code change. Other case seems don't need code change (Please correct me if I'm wrong)
- Change Bounded Staleness to Strong, to guarantee all region Read Your Write
- Change Session to Strong, to guarantee all region Read Your Write
- Degrade the consistency level back after temporarily increase the Consistency level.
I understand that changing other consistency level to session may need code change since that will need to respect the session token to guarantee Read Your Write. But could you help explain on what kind of code change is needed for from Session to Strong and Bounded Staleness. And from Strong to Bounded Staleness? Or point me to any doc for reference?
from azure-cosmos-dotnet-v3.
Thank you for the explanation! Then I guess the point of requiring the app to restart might also be to remind users that the potential code change is needed.
I still have some questions about raising the consistency level:
For Change Session to Strong or Bounded Staleness, will there be any drawback if we don't remove the session token part? I tested that the session token always exists for all consistency level. Is it only functionally work in the Session consistency? (For example, I keep the code for pass the session token, and raise the consistency level to Bounded staleness or Strong, will there make any difference comparing to removing that part of code?)
If I'm using the app service with Session Affinity enabled which can guarantee sticky routing (so I don't need to pass the session token), then changing the Session to Strong will have no difference in the code level?
In this case, if my read previous write request is going to a read region other than the write region, can it still guarantee get the latest version write record without using the session token?
from azure-cosmos-dotnet-v3.
I think this thread has great questions, I'll see if I can push some of them to the actual docs.
The service can return the SessionToken because it's part of the default response, and I agree that there might be some scenarios where the need for a restart might be "less" required than others. For example, if someone has 1 instance of the app running on a single machine, without any other architecture to support it, on an account with a single region, versus someone with a Redis cache to store user Session Token with load balancing distribution of requests across a farm of machines and deployed across multiple regions with local reads, the second one will require more adjustments than the first one. In a general sense of things, we can say that most of the apps will require some form of adjustment, so when documentation is written, the tendency is to generalize I guess. In case of the SDK, the ROI of the effort to wire this change throughout all the required places only to cover a small subset of scenarios might not be worth it (which was the discussion on the other linked issue).
if my read previous write request is going to a read region other than the write region, can it still guarantee get the latest version write record without using the session token?
On Strong, the Write and Read do what is called a Quorum check (see https://github.com/Azure/azure-cosmos-dotnet-v3/blob/master/docs/SdkDesign.md#consistency-direct-mode). It verifies that when a write is done, the LSN (transaction identifier) committed globally matches (so all regions have it) and this can affect latency. Depending on your app expectations (for example, a CancellationToken or some timeout mechanism expecting X latency), some code might need to change. On reads, there are 2 reads in parallel and it verifies that the Global committed LSN matches. So you should be able to read it regardless of which region you are reading from without the need of sticky routing (better load balancing).
As a side note, on a Session account, if you are using sticky routing then you don't need to pass the SessionToken, but if you are not using sticky routing, you should.
from azure-cosmos-dotnet-v3.
@blankor1 this issue requires more information for the team to be able to help. In case this information is available, please add it and re-open the Issue.
from azure-cosmos-dotnet-v3.
Related Issues (20)
- Microsoft.Azure.Cosmos.Encryption.Custom 1.0.0-preview06 is incompatible with Cosmos 3.40.0-preview.0 and newer
- Change Feed / Processor: AVAD timeToLiveExpired deserialization Issue
- LINQ support for specifying FilterPredicate
- Clarification on versioning practices of preview packages HOT 1
- Session-level consistency across multiple SDK clients/across different processes HOT 2
- Add New Zealand North region in Public Contract
- CosmosClientOptions.Request is not respected. HOT 5
- TelemetrySpan is not failures are not reflected in-case of non-exceptions
- Benchmark using not releasing
- invalid syntax for GetDatabase - closing paren is shown as closing square bracket HOT 1
- ReadManyItemsAsync -> ReadManyTaskHelperAsync wraps forked IO task into Task.Run
- AggregateException (instead of CosmosException) being thrown on GetFeedRanges when Gateway fails HOT 11
- Add client option to use the System.Text.Json Serializer instead of Newtonsoft ... HOT 2
- DiagnosticSourceName seems to be "Azure.Cosmos" not "Azure.Cosmos.Operation" in stable version SDK HOT 5
- Default JasonDotNet serializer maxdepth HOT 1
- Inquiry on Implementing Custom Retry Logic with CosmosClient HOT 1
- Blazor WebAssembly Hangs When Initializing CosmosClient Due to Task.Run in SystemUsageMonitor
- Operation 'POST' on resource 'dbs' is not allowed through Azure Cosmos DB endpoint. Please switch on such operations for your account, or perform this operation through Azure Resource Manager, Azure Portal, Azure CLI or Azure Powershell HOT 6
- Distributed Tracing/Open Telemetry: Feature requests HOT 1
- [Thin Client] Prepare Design Document for V3 SDK Integration
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from azure-cosmos-dotnet-v3.