We have a multiple writer scenario, where multiple processes can write to the same block blob. We are exploring the option to use ETag for optimistic concurrency. The storage client throws and exception if there is a conflict. Now conflicts are pretty normal and therefore throwing a lot of exceptions may reduce the throughput of a process. Is there a way to identify concurrent update, without throwing and exception from azure storage client.
1 Answers
0
votes
As far as I know, we couldn't directly identify concurrent update. Azure storage service check the blob is updated according to etag. If the etag isn't equal with the storage serve resource's etag. It will return 409 error in the response.
We have no permission to change the server return the 409 error response.
The only way is before updating the blob, we firstly ask for the etag.
But if another process update the blob, the etag changed, it will still return 409 error.
Here is a workaround. If you use azure storage SDK, it provide retry method, you could use this to avoid show the exception and resend the request to the azure to update the blob again. But the azure storage will still return the 409 response to the client.
If you use rest api, I suggest you could use try catch to catch the exception and retry sending rest api request again.
