Updated go, java, js drivers (#1262)

Co-authored-by: Matea Pesic <[email protected]>

Author: andrejtonev

pages/client-libraries/go.mdx

@@ -466,7 +466,7 @@ if err != nil {
     panic(err)
 }
 ```
-The `ExceuteQuery` method returns results in the `EagerResults` format, giving you access to the `Records` field. The records field contains all the records returned by the query. To process the results, you can iterate over the records and access the fields you need. 
+The `ExecuteQuery` method returns results in the `EagerResults` format, giving you access to the `Records` field. The records field contains all the records returned by the query. To process the results, you can iterate over the records and access the fields you need. 
 
 For example: 
 
@@ -651,6 +651,12 @@ If you want to read data from the database, here is an example of a managed tran
 	}
 ```
 
+
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as read or write and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+An exception will be thrown if the user tries to execute a write query inside a read transaction. See [transaction accessor misalignment](/help-center/errors/transactions#transaction-accessor-misalignment) for more details.
+</Callout>
+
 In the example above the `session.ExecuteRead` gets the function as an argument, the function is executed as a single transaction unit, and the result are returned from the function to the `session.ExecuteRead` method call. 
 
 Additional custom processing can be done on the result, such as running a second query inside the same transaction to return the wanted results. 
@@ -710,6 +716,11 @@ tx.Run(ctx, "CREATE (n:Technology {name:'Memgraph'});", nil)
 tx.Commit(ctx) // or tx.Rollback(ctx)
 ```
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as read or write and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+Explicit transactions can cover a number of individual queries, but storage access is given at the start. For best performance, the user needs to declare whether the transaction should use read or write access.
+This can be done by setting the session's `AccessMode` to `neo4j.AccessModeRead` or `neo4j.AccessModeWrite`. This will in turn set the access mode of a transaction created via the `BeginTransaction` function. Note that `ExecuteRead` and `ExecuteWrite` will override the session's default access.
+</Callout>
 
 Here is the full working example based on the explicit transaction: 
 
@@ -776,11 +787,15 @@ func getDevNodesByName(ctx context.Context, tx neo4j.ExplicitTransaction, name s
 
 ```
 
-##### Implicit transaction 
+##### Implicit transaction
 
 Implicit or auto-commit transactions won't be automatically retried as with `ExecuteQuery()` method or managed transactions.
-With implicit transactions, you don't have the same control over transactions as with managed transactions. This is the most primitive way of running transactions: 
+With implicit transactions, you don't have the same control over transactions as with managed transactions. This is the most primitive way of running transactions:
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as read or write and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+Access mode is automatically determined when executing single queries through implicit transactions.
+</Callout>
 
 ```go
 	session := driver.NewSession(ctx, neo4j.SessionConfig{DatabaseName: "memgraph"})

pages/client-libraries/java.mdx

@@ -376,6 +376,11 @@ public void createNode() {
 The session object takes a `SessionConfig` object as its argument. The `SessionConfig` object is used to specify the database name and other session configuration options. Session API supports `writeTransaction()` and `readTransaction()` methods.
 The `writeTransaction()` method takes a `TransactionWork` functional interface as its argument. The `TransactionWork` interface has a single method `execute()`, which takes a Transaction object `tx` as its argument and returns a value of generic type `T`, `void` in this case.
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+Using `writeTransaction` informs Memgraph that the transaction will be modifying data. See [transaction accessor misalignment](/fundamentals/transactions#transaction-accessor-misalignment) for more details.
+</Callout>
+
 #### Run a read query
 
 Similar to the write query, `readTranasction()` method can be used to run read queries. The difference is that read will return the results of the query.
@@ -402,6 +407,11 @@ public void readNode() {
 
 In the above query, each `Record` contains a `Node` accessible by the `asMap()` method.
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+An exception will be thrown if the user tries to execute a write query inside a read transaction. See [transaction accessor misalignment](/fundamentals/transactions#transaction-accessor-misalignment) for more details.
+</Callout>
+
 #### Running queries with property map
 
 If you want to pass a property map to the query, you can do it like this:
@@ -575,7 +585,7 @@ Keep in mind that, at the moment, Memgraph does not support Timezones, ByteArray
 
 Transaction is a unit of work that is executed on the database, it could be some basic read, write or complex set of steps in form of series of queries. There can be multiple ways to mange transaction, but usually, they are managed automatically by the driver or manually by the explicit code steps. Transaction management defines how to handle the transaction, when to commit, rollback, or terminate it.
 
-On the driver side, if a transaction fails because of a transient error, the transaction is retried automatically. 
+On the driver side, if a transaction fails because of a transient error, the transaction is retried automatically.
 The transient error will occur during write conflicts or network failures. The driver will retry the transaction function with an exponentially increasing delay.
 
 #### Simple transaction management
@@ -630,11 +640,22 @@ public void createNode() {
 All the previous examples from this guide have used simple transaction management. It allows you to run multiple queries in a single transaction and have control over the transaction. You could have multiple logic blocks in the transaction, rollback or end the transaction if needed.
 Also, managed transactions have a retry logic, which means that if the transaction fails, it will be retried. Managed transactions are the most flexible way to run a Cypher query.
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+Using `writeTransaction` and `readTransaction` informs Memgraph what type of access is required for the transaction.
+An exception will be thrown if the user tries to execute a write query inside a read transaction. See [transaction accessor misalignment](/fundamentals/transactions#transaction-accessor-misalignment) for more details.
+</Callout>
+
 ##### Implicit transactions
 
 Implicit auto-commit queries are the simplest way to run a Cypher query since they aren't automatically retried like `writeTransaction` and `readTransaction` are.
 With implicit auto-commit transactions, you don't have the same control of transactions as with managed explicit transactions.
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+For single query implicit transaction, no user input is required, Memgraph will deduce the access type needed at parse-time. See [transaction accessor misalignment](/fundamentals/transactions#transaction-accessor-misalignment) for more details.
+</Callout>
+
 Here is an example of an implicit transaction:
 
 ```java
@@ -670,6 +691,12 @@ You can use the following transaction management methods via async session API:
 
 ##### Managed transactions
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+Using `executeReadAsync` and `executeWriteAsync` informs Memgraph what type of access is required for the transaction.
+An exception will be thrown if the user tries to execute a write query inside a read transaction. See [transaction accessor misalignment](/fundamentals/transactions#transaction-accessor-misalignment) for more details.
+</Callout>
+
 Here is a basic example of reading data from the database via Async session API:
 
 ```java
@@ -689,6 +716,11 @@ public CompletionStage<ResultSummary> readNodesAsync() {
 
 Implicit auto-commit queries are the simplest way to run a Cypher query since they aren't automatically retried like `writeTransactionAsync` and `readTransactionAsync` are.
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+For single query implicit transaction, no user input is required, Memgraph will deduce the access type needed at parse-time. See [transaction accessor misalignment](/fundamentals/transactions#transaction-accessor-misalignment) for more details.
+</Callout>
+
 Here is an example of an implicit transaction:
 
 ```java
@@ -706,6 +738,6 @@ public CompletionStage<ResultSummary> createNodeAsync() {
 
 If you encounter serialization errors while using Java client, we recommend
 referring to our [Serialization errors](/help-center/errors/serialization) page
-for detailed guidance on troubleshooting and best practices. 
+for detailed guidance on troubleshooting and best practices.
 
 </Callout>

pages/client-libraries/javascript.mdx

@@ -500,6 +500,11 @@ a transaction to encapsulate the Cypher queries you're executing. This automatic
 transaction management simplifies the process of working with transactions. 
 That method should be used when transaction control is unnecessary. 
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+For single query automatic transaction, no user input is required, Memgraph will deduce the access type needed at parse-time. See [transaction accessor misalignment](/fundamentals/transactions#transaction-accessor-misalignment) for more details.
+</Callout>
+
 #### Manual transactions
 
 Before running a transaction, you need to obtain a *session*. Sessions act 
@@ -567,14 +572,26 @@ Because of this, it is impossible to know how many time the transaction is going
 rely on globals. Note that although transaction functions might be 
 executed multiple times, the queries inside it will always run only once.
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+Using `executeRead` and `executeWrite` informs Memgraph what type of access is required for the transaction.
+An exception will be thrown if the user tries to execute a write query inside a read transaction. See [transaction accessor misalignment](/fundamentals/transactions#transaction-accessor-misalignment) for more details.
+</Callout>
+
 ##### Explicit transactions
 
 You can achieve full control over transactions by manually starting them using the 
 `session.beginTransaction()` method. You run queries inside an explicit transaction 
 with the `Transaction.run()` method, as you do in transaction functions.
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+Explicit transactions can cover a number of individual queries, but storage access is given at the start. For best performance, the user needs to declare whether the transaction should use read or write access.
+This can be done by setting the session's `defaultAccessMode` to `'READ'` or `'WRITE'`. This will, in turn, set the access mode of a transaction created via the `begin_transaction` function. Note that `executeRead` and `executeWrite` will override the session's default access.
+</Callout>
+
 ```js
-let session = driver.session({ database: 'neo4j' })
+let session = driver.session({ database: 'neo4j', defaultAccessMode: 'READ' })
 let transaction = await session.beginTransaction()
 
 // await transaction.run('<QUERY 1>')
@@ -599,4 +616,4 @@ If you encounter serialization errors while using JavaScript client, we recommen
 referring to our [Serialization errors](/help-center/errors/serialization) page
 for detailed guidance on troubleshooting and best practices. 
 
-</Callout>
+</Callout>

pages/client-libraries/nodejs.mdx

@@ -550,6 +550,11 @@ a transaction to encapsulate the Cypher queries you're executing. This automatic
 transaction management simplifies the process of working with transactions. 
 That method should be used when transaction control is unnecessary. 
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+For single query automatic transaction, no user input is required, Memgraph will deduce the access type needed at parse-time. See [transaction accessor misalignment](/fundamentals/transactions#transaction-accessor-misalignment) for more details.
+</Callout>
+
 ##### Process partial results
 
 When dealing with queries that may take considerable time to execute or have a
@@ -672,13 +677,25 @@ when run several times. This means you shouldn't, for example, edit or rely on
 globals. Note that although transaction functions might be executed multiple 
 times, the queries inside it will always run only once.
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+Using `executeRead` and `executeWrite` informs Memgraph what type of access is required for the transaction.
+An exception will be thrown if the user tries to execute a write query inside a read transaction. See [transaction accessor misalignment](/fundamentals/transactions#transaction-accessor-misalignment) for more details.
+</Callout>
+
 ##### Explicit transactions
 
 You can achieve full control over transactions by manually starting them using 
 the `session.beginTransaction()` method. You run queries inside an explicit 
 transaction with the `Transaction.run()` method, as you do in transaction 
 functions.
 
+<Callout type="info">
+As of Memgraph version 3.2, queries are categorized as **read** or **write** and the corresponding storage access is taken. This allows for better query parallelization and higher throughput.
+Explicit transactions can cover a number of individual queries, but storage access is given at the start. For best performance, the user needs to declare whether the transaction should use read or write access.
+This can be done by setting the session's `defaultAccessMode` to `'READ'` or `'WRITE'`. This will, in turn, set the access mode of a transaction created via the `begin_transaction` function. Note that `executeRead` and `executeWrite` will override the session's default access.
+</Callout>
+
 ```js
 let session = driver.session({ database: 'neo4j' })
 let transaction = await session.beginTransaction()