dapr
/
docs
mirror of https://github.com/dapr/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Removing the "database" nomenclature 

In favor of state store, since that's a better description of what Dapr provides
This commit is contained in:
Aaron Schlesinger 2020-05-12 15:11:14 -07:00
parent 0ffd73e00e
commit 9793cfd251
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
concepts/state-management/README.md
View File

@ -1,6 +1,6 @@
# State management
Dapr comes with APIs for a key/value storage system, called "state management" in Dapr terminology. If your microservice uses state management, it automatically gets access to any of the [supported databases](https://github.com/dapr/docs/blob/master/howto/setup-state-store/supported-state-stores.md), without adding or learning a third party SDK.
Dapr comes with APIs for a key/value storage system, called "state management" in Dapr terminology. If your microservice uses state management, it automatically gets access to any of the [supported state stores](https://github.com/dapr/docs/blob/master/howto/setup-state-store/supported-state-stores.md), without adding or learning a third party SDK.
State management requires that you build your application with several rules in mind, and if you follow those rules, your app will also be able to leverage several other features that would otherwise be complicated and error-prone to build yourself:
@ -55,7 +55,7 @@ SQL Server | Yes | Yes | Yes
## Concurrency
Dapr supports optimistic concurrency control (OCC) using ETags. When a state is requested, Dapr always attaches an **ETag** property to the returned state. And when the user code tries to update or delete a state, it's expected to attach the ETag through the **If-Match** header. The write operation can succeed only when the provided ETag matches with the ETag in the database.
Dapr supports optimistic concurrency control (OCC) using ETags. When a state is requested, Dapr always attaches an **ETag** property to the returned state. And when the user code tries to update or delete a state, it's expected to attach the ETag through the **If-Match** header. The write operation can succeed only when the provided ETag matches with the ETag in the state store.
Dapr chooses OCC because in many applications, data update conflicts are rare because clients are naturally partitioned by business contexts to operate on different data. However, if your application chooses to use ETags, a request may get rejected because of mismatched ETags. It's recommended that you use a [Retry Policy](#Retry-Policies) to compensate for such conflicts when using ETags.