Previously, each Cluster session would lazily create Core sessions on-demand as Transactions were opened. This delegated too much responsibility to the Transaction. Now, each Cluster session is bound to a single server node, which may be a primary or a secondary node depending on the Options passed to the Session.
We also select secondary nodes in a fairer, more balanced way; the server indicates which node is its first preference for secondary sessions, and the client tries to obey the server's decision, with fallback to backup nodes only in the event of a failure.
What are the changes implemented in this PR?
On creating a Cluster session, a Core session is immediately created to a server node of the appropriate type
Node selection is based on the read_any_replica Option passed to the Session
When read_any_replica is true, the client will first select nodes that the server has indicated are "preferred secondary", with fallback to backup nodes only in the event of a failure
What is the goal of this PR?
Previously, each Cluster session would lazily create Core sessions on-demand as Transactions were opened. This delegated too much responsibility to the Transaction. Now, each Cluster session is bound to a single server node, which may be a primary or a secondary node depending on the Options passed to the Session.
We also select secondary nodes in a fairer, more balanced way; the server indicates which node is its first preference for secondary sessions, and the client tries to obey the server's decision, with fallback to backup nodes only in the event of a failure.
What are the changes implemented in this PR?
read_any_replicaOption passed to the Sessionread_any_replicaistrue, the client will first select nodes that the server has indicated are "preferred secondary", with fallback to backup nodes only in the event of a failure