CompareExchange and Document updates in a session.

[BernhardGlueck]

I have a question about the interaction between compare exchange values and document updates in a session.

I need to create one new document and update and existing one in an atomic fashion while ensuring that the document to be updated was not changed by someone else. ( cluster wide )

Since this a potentially long running ( think hours ) between the intent to update and the actual update i cannot use automatic atomic guards.

My approach is to create a compare exchange value for the documen to be updated ( on initial creation )
And then

1. Get the value of that compare exchage value, and the raft index
2. Store that in another document ( which is user private so no concurrent updates there )
3. When it comes time to update i woud like to do

session.Store(updatedDocument)
session.Store(newDocument)
session.Advanced.ClusterTransaction.UpdateCompareExchange(key,StoredIndex)

session.SaveChanges();

The problem is that there seems to be no operation UpdateCompareExchange ... only create a new one and throw when it already exists. What is the correct way to do this ?

And secondly IF that would work. would since this is only a single transaction ( one single call to savechanges ) the whole 3 writes fail and be rolled back ? ( Which would be the desired outcome ? )

[karmeli87]

Hi,

If you are going through the session then all operations (document related & compare exchange) are executed in an atomic fashion, either all succeed or all fail.

You don't need to do anything special, when you call session.Advanced.ClusterTransaction.GetCompareExchangeValueAsync the compare exchange value is tracked by the session so the changes done to the Value will be automatically sent to the server upon calling the SaveChanges.

I'm not fully follow what you are trying to achieve here, but I think you can avoid the compare exchange by having some property on the document for concurrency check.
Something like "ReservedFor" : "Users/123".
At the beginning it might be null so any session may try to update it, and upon concurrent updates only one will succeed while others will fail.
But once it is updated your application logic can ensure that no other session can modify this.

[BernhardGlueck]

Thank you very much, that helps a lot.