Mixing
Concurrency on DocumentDB
This is a newby question on DocumentDB. We want to use DocumentDB for our application. We have multiple users changing data that is stored in a DocumentDB. How can we asure that one user does not overwrite the changes of another user?
azure azure-cosmosdb edited Apr 5 '17 at 15:39
Jim Aho
2,34922545
asked Jun 30 '16 at 12:54
JVermeulenJVermeulen
10018
add a comment |
This is a newby question on DocumentDB. We want to use DocumentDB for our application. We have multiple users changing data that is stored in a DocumentDB. How can we asure that one user does not overwrite the changes of another user?
azure azure-cosmosdb edited Apr 5 '17 at 15:39
Jim Aho
2,34922545
asked Jun 30 '16 at 12:54
JVermeulenJVermeulen
10018
1
Please flip the accepted answer
– Ruben Bartelink
Nov 13 '18 at 2:41
add a comment |
This is a newby question on DocumentDB. We want to use DocumentDB for our application. We have multiple users changing data that is stored in a DocumentDB. How can we asure that one user does not overwrite the changes of another user?
azure azure-cosmosdb edited Apr 5 '17 at 15:39
Jim Aho
2,34922545
asked Jun 30 '16 at 12:54
JVermeulenJVermeulen
10018
This is a newby question on DocumentDB. We want to use DocumentDB for our application. We have multiple users changing data that is stored in a DocumentDB. How can we asure that one user does not overwrite the changes of another user?
azure azure-cosmosdb azure azure-cosmosdb edited Apr 5 '17 at 15:39
Jim Aho
2,34922545
asked Jun 30 '16 at 12:54
JVermeulenJVermeulen
10018
edited Apr 5 '17 at 15:39
Jim Aho
2,34922545
asked Jun 30 '16 at 12:54
JVermeulenJVermeulen
10018
edited Apr 5 '17 at 15:39
Jim Aho
2,34922545
edited Apr 5 '17 at 15:39
Jim Aho
2,34922545
edited Apr 5 '17 at 15:39
Jim Aho
2,34922545
2,34922545
asked Jun 30 '16 at 12:54
JVermeulenJVermeulen
10018
asked Jun 30 '16 at 12:54
JVermeulenJVermeulen
10018
asked Jun 30 '16 at 12:54
JVermeulenJVermeulen
10018
10018
1
Please flip the accepted answer
– Ruben Bartelink
Nov 13 '18 at 2:41
add a comment |
1
Please flip the accepted answer
– Ruben Bartelink
Nov 13 '18 at 2:41
1
1
Please flip the accepted answer
– Ruben Bartelink
Nov 13 '18 at 2:41
Please flip the accepted answer
– Ruben Bartelink
Nov 13 '18 at 2:41
add a comment |
2 Answers
2
active
oldest
votes
DocumentDB does not protect against concurrency. If you post a new version of the document over an existing the old document will be overwritten. If you can to protect against concurrent writes you have to use the timestamp of the document. Every document in documentDB has a timestamp of the last action.
On every update you can check if the timestamp of the document you want to update is equal to the one that you retrieved or if it has changed. If is has changed the user does not have the most recent version and you can cancel the update.
The best thing is to create a stored procedure so you can put this logic inside a stored proc and make your application agnostic of it.
answered Jun 30 '16 at 15:05
Sander van den HovenSander van den Hoven
656144
4
There's a built-in ETag mechanism that deals specifically with this. Checking timestamp won't prevent the server from rejecting writes based on ETag (two writers can check for timestamp simultaneously).
– David Makogon
Jun 30 '16 at 15:06
1
David's is really the better answer here. "Optimistic concurrency", "ETag", these are the correct terms. It's not apparent that the ETag is a timestamp. Also, I would not say sprocs are best for this simple situation of writes coming from two users. The ETag mechanism is simpler and easier to deal with error handling than sprocs. Sprocs might be best if you are reading and writing in the same transaction or if you are doing multiple writes that need to be consistent with each other. I also favor sprocs for writes to do data validation.
– Larry Maccherone
Jun 30 '16 at 19:45
add a comment |
DocumentDB has optimistic concurrency and has an ETag on each document. If the ETag has changed when doing a write, the write fails (if the ETag changed, that means someone else modified the document). In this condition, you'd need to re-read and re-modify the document in question.
See the faq here for more info.
answered Jun 30 '16 at 15:05
David MakogonDavid Makogon
57.4k15109157
2
Specifically you can use the request options and accessCondition property to provide the etag and IfMatch condition.
– njappboy
Oct 27 '16 at 23:38
1
peter.intheazuresky.com/2016/04/28/… has more detail on ETag usage.
– njappboy
Dec 9 '16 at 17:54
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f38123752%2fconcurrency-on-documentdb%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
DocumentDB does not protect against concurrency. If you post a new version of the document over an existing the old document will be overwritten. If you can to protect against concurrent writes you have to use the timestamp of the document. Every document in documentDB has a timestamp of the last action.
On every update you can check if the timestamp of the document you want to update is equal to the one that you retrieved or if it has changed. If is has changed the user does not have the most recent version and you can cancel the update.
The best thing is to create a stored procedure so you can put this logic inside a stored proc and make your application agnostic of it.
answered Jun 30 '16 at 15:05
Sander van den HovenSander van den Hoven
656144
4
There's a built-in ETag mechanism that deals specifically with this. Checking timestamp won't prevent the server from rejecting writes based on ETag (two writers can check for timestamp simultaneously).
– David Makogon
Jun 30 '16 at 15:06
1
David's is really the better answer here. "Optimistic concurrency", "ETag", these are the correct terms. It's not apparent that the ETag is a timestamp. Also, I would not say sprocs are best for this simple situation of writes coming from two users. The ETag mechanism is simpler and easier to deal with error handling than sprocs. Sprocs might be best if you are reading and writing in the same transaction or if you are doing multiple writes that need to be consistent with each other. I also favor sprocs for writes to do data validation.
– Larry Maccherone
Jun 30 '16 at 19:45
add a comment |
DocumentDB does not protect against concurrency. If you post a new version of the document over an existing the old document will be overwritten. If you can to protect against concurrent writes you have to use the timestamp of the document. Every document in documentDB has a timestamp of the last action.
On every update you can check if the timestamp of the document you want to update is equal to the one that you retrieved or if it has changed. If is has changed the user does not have the most recent version and you can cancel the update.
The best thing is to create a stored procedure so you can put this logic inside a stored proc and make your application agnostic of it.
answered Jun 30 '16 at 15:05
Sander van den HovenSander van den Hoven
656144
4
There's a built-in ETag mechanism that deals specifically with this. Checking timestamp won't prevent the server from rejecting writes based on ETag (two writers can check for timestamp simultaneously).
– David Makogon
Jun 30 '16 at 15:06
1
David's is really the better answer here. "Optimistic concurrency", "ETag", these are the correct terms. It's not apparent that the ETag is a timestamp. Also, I would not say sprocs are best for this simple situation of writes coming from two users. The ETag mechanism is simpler and easier to deal with error handling than sprocs. Sprocs might be best if you are reading and writing in the same transaction or if you are doing multiple writes that need to be consistent with each other. I also favor sprocs for writes to do data validation.
– Larry Maccherone
Jun 30 '16 at 19:45
add a comment |
DocumentDB does not protect against concurrency. If you post a new version of the document over an existing the old document will be overwritten. If you can to protect against concurrent writes you have to use the timestamp of the document. Every document in documentDB has a timestamp of the last action.
On every update you can check if the timestamp of the document you want to update is equal to the one that you retrieved or if it has changed. If is has changed the user does not have the most recent version and you can cancel the update.
The best thing is to create a stored procedure so you can put this logic inside a stored proc and make your application agnostic of it.
answered Jun 30 '16 at 15:05
Sander van den HovenSander van den Hoven
656144
DocumentDB does not protect against concurrency. If you post a new version of the document over an existing the old document will be overwritten. If you can to protect against concurrent writes you have to use the timestamp of the document. Every document in documentDB has a timestamp of the last action.
On every update you can check if the timestamp of the document you want to update is equal to the one that you retrieved or if it has changed. If is has changed the user does not have the most recent version and you can cancel the update.
The best thing is to create a stored procedure so you can put this logic inside a stored proc and make your application agnostic of it.
answered Jun 30 '16 at 15:05
Sander van den HovenSander van den Hoven
656144
answered Jun 30 '16 at 15:05
Sander van den HovenSander van den Hoven
656144
answered Jun 30 '16 at 15:05
Sander van den HovenSander van den Hoven
656144
answered Jun 30 '16 at 15:05
Sander van den HovenSander van den Hoven
656144
656144
4
There's a built-in ETag mechanism that deals specifically with this. Checking timestamp won't prevent the server from rejecting writes based on ETag (two writers can check for timestamp simultaneously).
– David Makogon
Jun 30 '16 at 15:06
1
David's is really the better answer here. "Optimistic concurrency", "ETag", these are the correct terms. It's not apparent that the ETag is a timestamp. Also, I would not say sprocs are best for this simple situation of writes coming from two users. The ETag mechanism is simpler and easier to deal with error handling than sprocs. Sprocs might be best if you are reading and writing in the same transaction or if you are doing multiple writes that need to be consistent with each other. I also favor sprocs for writes to do data validation.
– Larry Maccherone
Jun 30 '16 at 19:45
add a comment |
4
There's a built-in ETag mechanism that deals specifically with this. Checking timestamp won't prevent the server from rejecting writes based on ETag (two writers can check for timestamp simultaneously).
– David Makogon
Jun 30 '16 at 15:06
1
David's is really the better answer here. "Optimistic concurrency", "ETag", these are the correct terms. It's not apparent that the ETag is a timestamp. Also, I would not say sprocs are best for this simple situation of writes coming from two users. The ETag mechanism is simpler and easier to deal with error handling than sprocs. Sprocs might be best if you are reading and writing in the same transaction or if you are doing multiple writes that need to be consistent with each other. I also favor sprocs for writes to do data validation.
– Larry Maccherone
Jun 30 '16 at 19:45
4
4
There's a built-in ETag mechanism that deals specifically with this. Checking timestamp won't prevent the server from rejecting writes based on ETag (two writers can check for timestamp simultaneously).
– David Makogon
Jun 30 '16 at 15:06
There's a built-in ETag mechanism that deals specifically with this. Checking timestamp won't prevent the server from rejecting writes based on ETag (two writers can check for timestamp simultaneously).
– David Makogon
Jun 30 '16 at 15:06
1
1
David's is really the better answer here. "Optimistic concurrency", "ETag", these are the correct terms. It's not apparent that the ETag is a timestamp. Also, I would not say sprocs are best for this simple situation of writes coming from two users. The ETag mechanism is simpler and easier to deal with error handling than sprocs. Sprocs might be best if you are reading and writing in the same transaction or if you are doing multiple writes that need to be consistent with each other. I also favor sprocs for writes to do data validation.
– Larry Maccherone
Jun 30 '16 at 19:45
David's is really the better answer here. "Optimistic concurrency", "ETag", these are the correct terms. It's not apparent that the ETag is a timestamp. Also, I would not say sprocs are best for this simple situation of writes coming from two users. The ETag mechanism is simpler and easier to deal with error handling than sprocs. Sprocs might be best if you are reading and writing in the same transaction or if you are doing multiple writes that need to be consistent with each other. I also favor sprocs for writes to do data validation.
– Larry Maccherone
Jun 30 '16 at 19:45
add a comment |
DocumentDB has optimistic concurrency and has an ETag on each document. If the ETag has changed when doing a write, the write fails (if the ETag changed, that means someone else modified the document). In this condition, you'd need to re-read and re-modify the document in question.
See the faq here for more info.
answered Jun 30 '16 at 15:05
David MakogonDavid Makogon
57.4k15109157
2
Specifically you can use the request options and accessCondition property to provide the etag and IfMatch condition.
– njappboy
Oct 27 '16 at 23:38
1
peter.intheazuresky.com/2016/04/28/… has more detail on ETag usage.
– njappboy
Dec 9 '16 at 17:54
add a comment |
DocumentDB has optimistic concurrency and has an ETag on each document. If the ETag has changed when doing a write, the write fails (if the ETag changed, that means someone else modified the document). In this condition, you'd need to re-read and re-modify the document in question.
See the faq here for more info.
answered Jun 30 '16 at 15:05
David MakogonDavid Makogon
57.4k15109157
2
Specifically you can use the request options and accessCondition property to provide the etag and IfMatch condition.
– njappboy
Oct 27 '16 at 23:38
1
peter.intheazuresky.com/2016/04/28/… has more detail on ETag usage.
– njappboy
Dec 9 '16 at 17:54
add a comment |
DocumentDB has optimistic concurrency and has an ETag on each document. If the ETag has changed when doing a write, the write fails (if the ETag changed, that means someone else modified the document). In this condition, you'd need to re-read and re-modify the document in question.
See the faq here for more info.
answered Jun 30 '16 at 15:05
David MakogonDavid Makogon
57.4k15109157
DocumentDB has optimistic concurrency and has an ETag on each document. If the ETag has changed when doing a write, the write fails (if the ETag changed, that means someone else modified the document). In this condition, you'd need to re-read and re-modify the document in question.
See the faq here for more info.
answered Jun 30 '16 at 15:05
David MakogonDavid Makogon
57.4k15109157
answered Jun 30 '16 at 15:05
David MakogonDavid Makogon
57.4k15109157
answered Jun 30 '16 at 15:05
David MakogonDavid Makogon
57.4k15109157
answered Jun 30 '16 at 15:05
David MakogonDavid Makogon
57.4k15109157
57.4k15109157
2
Specifically you can use the request options and accessCondition property to provide the etag and IfMatch condition.
– njappboy
Oct 27 '16 at 23:38
1
peter.intheazuresky.com/2016/04/28/… has more detail on ETag usage.
– njappboy
Dec 9 '16 at 17:54
add a comment |
2
Specifically you can use the request options and accessCondition property to provide the etag and IfMatch condition.
– njappboy
Oct 27 '16 at 23:38
1
peter.intheazuresky.com/2016/04/28/… has more detail on ETag usage.
– njappboy
Dec 9 '16 at 17:54
2
2
Specifically you can use the request options and accessCondition property to provide the etag and IfMatch condition.
– njappboy
Oct 27 '16 at 23:38
Specifically you can use the request options and accessCondition property to provide the etag and IfMatch condition.
– njappboy
Oct 27 '16 at 23:38
1
1
peter.intheazuresky.com/2016/04/28/… has more detail on ETag usage.
– njappboy
Dec 9 '16 at 17:54
peter.intheazuresky.com/2016/04/28/… has more detail on ETag usage.
– njappboy
Dec 9 '16 at 17:54
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f38123752%2fconcurrency-on-documentdb%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Please flip the accepted answer
– Ruben Bartelink
Nov 13 '18 at 2:41