Concurrency Questions

[murshex]

I have a couple of questions regarding concurrency:

• Before RavenDB 5.2, what was the benefit of using cluster wide transactions without using compare exchange?
• Right now I only have a single RavenDB node, should I use cluster wide transactions instead of optimistic concurrency in case in the future I want to use a cluster?

Thank you

[ayende]

• Before 5.2 - you could combine them with compare exchange for consistency.
• The scenario for their use without compare exchange is somewhat esoteric. Basically, it ensures a level of consistency in the cluster.

The following is solely about pre 5.2 cluster transactions (or cluster transactions today with disabling atomic guards, not recommended):

The transaction in this case isn't executed on the node that accepts it. Instead, it is distributed on the cluster and only once a majority of the nodes in the cluster accepted it will it be written.
Any follow up action from the client after the transaction complete must see the transaction in any node it is using.

Consider:

• Client send to A, single node tx committed (locally)
• Client talks to B, the tx hasn't replicated yet, they see older data

Versus:

• Client send to A, cluster wide tx
• A send to B & C - waits until C confirms the write (so we have 2/3 majority) before talking to client
• Client get ack from A, with the transaction id
• Client talks to B (sending the minimum acceptable tx id), and B will wait to reply until the transaction has been committed locally.

[murshex]

“Consider” is how non cluster wide transactions work and “Versus” is how cluster wide transactions prior to RavenDB 5.2 work, right?

[ayende]

Yes.

[murshex]

So can we say that the benefit of cluster wide transactions before RavenDB 5.2 without compare exchange only applies to a single client, thats why compare exchange is used, to ensure consistency across all clients

[ayende]

Yes, but note that this client is "process wide".

[murshex]

Okay… roger that

[ayende]

Cluster wide transactions vs. optimistic concurrency serve very different needs.
I would recommend using optimistic concurrency for now, unless you actually need (or likely to need) cluster wide transactions in the future.

[murshex]

Okay, got it… thanks a lot