Change leader to primaries in clustering remarks.

go-manual/modules/ROOT/pages/query-simple.adoc

@@ -221,7 +221,7 @@ neo4j.ExecuteQuery(ctx, driver,
 
 [NOTE]
 ====
-Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.* The difference between the two modes is that _read_ transactions will be routed to any node of a cluster, whereas _write_ ones will be directed to the leader.
+Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.* The difference between the two modes is that _read_ transactions will be routed to any node of a cluster, whereas _write_ ones are directed to primaries.
 In other words, there is no guarantee that a write query submitted in read mode will be rejected.
 ====
 

go-manual/modules/ROOT/pages/transactions.adoc

@@ -486,7 +486,7 @@ session := driver.NewSession(ctx, neo4j.SessionConfig{
 // .Routing ≠ Access control
 [NOTE]
 ====
-Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.* The difference between the two modes is that _read_ transactions will be routed to any node of a cluster, whereas _write_ ones will be directed to the leader.
+Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.* The difference between the two modes is that _read_ transactions will be routed to any node of a cluster, whereas _write_ ones are directed to primaries.
 In other words, there is no guarantee that a write query submitted in read mode will be rejected.
 
 Similar remarks hold for the `.ExecuteRead()` and `.ExecuteWrite()` methods.

java-manual/modules/ROOT/pages/query-simple.adoc

@@ -228,7 +228,7 @@ var result = driver.executableQuery("MATCH (p:Person) RETURN p.name")
 
 [NOTE]
 ====
-Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.* The difference between the two modes is that _read_ transactions will be routed to any node of a cluster, whereas _write_ ones will be directed to the leader.
+Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.* The difference between the two modes is that _read_ transactions will be routed to any node of a cluster, whereas _write_ ones are directed to primaries.
 In other words, there is no guarantee that a write query submitted in read mode will be rejected.
 ====
 

java-manual/modules/ROOT/pages/transactions.adoc

@@ -439,7 +439,7 @@ var session = driver.session(SessionConfig.builder()
 [NOTE]
 ====
 Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.*
-The difference between the two modes is that _read_ transactions are routed to any node of a cluster, whereas _write_ ones are directed to the leader.
+The difference between the two modes is that _read_ transactions are routed to any node of a cluster, whereas _write_ ones are directed to primaries.
 In other words, there is no guarantee that a write query submitted in read mode will be rejected.
 
 Similar remarks hold for the `.executeRead()` and `.executeWrite()` methods.

javascript-manual/modules/ROOT/pages/query-simple.adoc

@@ -204,7 +204,7 @@ await driver.executeQuery(
 
 [NOTE]
 ====
-Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.* The difference between the two modes is that _read_ transactions will be routed to any node of a cluster, whereas _write_ ones will be directed to the leader.
+Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.* The difference between the two modes is that _read_ transactions will be routed to any node of a cluster, whereas _write_ ones are directed to primaries.
 In other words, there is no guarantee that a write query submitted in read mode will be rejected.
 ====
 

javascript-manual/modules/ROOT/pages/transactions.adoc

@@ -322,7 +322,7 @@ const session = driver.session({
 [NOTE]
 ====
 Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.*
-The difference between the two modes is that _read_ transactions are routed to any node of a cluster, whereas _write_ ones are directed to the leader.
+The difference between the two modes is that _read_ transactions are routed to any node of a cluster, whereas _write_ ones are directed to primaries.
 In other words, there is no guarantee that a write query submitted in read mode will be rejected.
 
 Similar remarks hold for the `.executeRead()` and `.executeWrite()` methods.

python-manual/modules/ROOT/pages/query-simple.adoc

@@ -210,7 +210,7 @@ driver.execute_query(
 
 [NOTE]
 ====
-Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.* The difference between the two modes is that _read_ transactions will be routed to any node of a cluster, whereas _write_ ones will be directed to the leader.
+Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.* The difference between the two modes is that _read_ transactions will be routed to any node of a cluster, whereas _write_ ones are directed to primaries.
 In other words, there is no guarantee that a write query submitted in read mode will be rejected.
 ====
 

python-manual/modules/ROOT/pages/transactions.adoc

@@ -402,7 +402,7 @@ with driver.session(
 [NOTE]
 ====
 Although executing a _write_ query in read mode likely results in a runtime error, *you should not rely on this for access control.*
-The difference between the two modes is that _read_ transactions are routed to any node of a cluster, whereas _write_ ones are directed to the leader.
+The difference between the two modes is that _read_ transactions are routed to any node of a cluster, whereas _write_ ones are directed to primaries.
 In other words, there is no guarantee that a write query submitted in read mode will be rejected.
 
 Similar remarks hold for the `.executeRead()` and `.executeWrite()` methods.