wip

Author: andrejtonev

pages/client-libraries/python.mdx

@@ -326,6 +326,8 @@ client.execute_query(node)
 ```
 
 Due to the nature of the `execute_query()` method, transactions are handled automatically.
+As of Memgraph version 3.2, queries are categorized as read/write and corresponding storage access given. This allows for better query parallelization and higher throughput.
+Single query execution does not need to be explicitly marked by the user. The query is analyzed and the access type determined.
 
 #### Run a read query
 
@@ -342,6 +344,8 @@ for record in records:
 ```
 
 In this query, each record contains a node object behind the variable `n`.
+As of Memgraph version 3.2, queries are categorized as read/write and corresponding storage access given. This allows for better query parallelization and higher throughput.
+Single query execution does not need to be explicitly marked by the user. The query is analyzed and the access type determined.
 
 #### Running queries with property map
 
@@ -545,6 +549,8 @@ With sessions, you can run:
 ##### Managed transactions
 
 To create a managed transaction, use `Session.execute_read()` procedure for read queries and `Session.execute_write()` procedure for write queries.
+As of Memgraph version 3.2, queries are categorized as read/write and corresponding storage access given. This allows for better query parallelization and higher throughput.
+
 
 ```python
 def match_user(tx, name):
@@ -581,6 +587,12 @@ To maintain multiple concurrent transactions, use [multiple concurrent sessions]
 With explicit transactions, you can get **complete control over transactions**. To begin a transaction, run `Session.begin_transaction()` procedure and to run a transaction, use `Transaction.run()` procedure.
 Explicit transactions offer the possibility of explicitly controlling the end of a transaction with `Transaction.commit()`, `Transaction.rollback()` or `Transaction.close()` methods.
 
+As of Memgraph version 3.2, queries are categorized as read/write and corresponding storage access given. This allows for better query parallelization and higher throughput.
+Explicit transactions 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:
+1. calling `begin_transaction(mode="r"/"w")`, here `mode` explicitly defines whether the transaction should take a read ("r") or write ("w") access
+1. using `read_transaction()` or `write_transaction()` in place of `begin_transaction()`
+
 Use explicit transaction if you need to **distribute Cypher execution across multiple functions for the same transaction** or if you need to **run multiple queries within a single transactions without automatic retries**.
 
 The following example shows how to explicitly control the transaction of changing account balances based on a token transfer:

pages/help-center/errors/transactions.mdx

@@ -119,15 +119,17 @@ Here are the [instructions](/configuration/configuration-settings#using-flags-an
 
 Here are the storage access error messages you might encounter:
 
-1. **Cannot access storage, unique access query is running. Try again later.**
+1. **Cannot get shared access storage. Try stopping other queries that are running in parallel.**
 2. **Cannot get unique access to the storage. Try stopping other queries that are running in parallel.**
+3. **Cannot get read only access to the storage. Try stopping other queries that are running in parallel.**
 
 ### Understanding storage access timeout
 
 Storage access timeouts occur during query preparation when the query execution engine cannot get the required type of access to the storage. There are two types of storage access:
 
-- **Shared access**: Multiple queries can have shared access at the same time, but shared access cannot be granted while a query with unique access is running.
+- **Shared access**: Multiple queries can have shared access at the same time. These queries are marked with a read or write type, allowing Memgraph to efficiently execute multiple operations in parallel without conflicts, as long as no unique access is required.
 - **Unique access**: Only one query can have unique access at a time, and no other query can have any type of access during that period.
+- **Read-only access**: Queries with read-only access allow other read queries to run in parallel but forbid any write operations or queries requiring unique access.
 
 These timeouts prevent worker starvation and database blocking that could occur if queries were to wait indefinitely for storage access.