Touch

Author: andrejtonev

pages/help-center/errors/transactions.mdx

@@ -1,6 +1,6 @@
 ---
 title: Transactions
-description: Learn about transaction errors that can occur in Memgraph and what to do when you encounter them. 
+description: Learn about transaction errors that can occur in Memgraph and what to do when you encounter them.
 ---
 
 import { Callout } from 'nextra/components'
@@ -23,15 +23,15 @@ While working with Memgraph, you can encounter various transaction errors. Here
 
 ### Handling conflicting transaction and serialization error
 
-Conflicting transactions and serialization errors are, in a sense, the same error that usually occurs when concurrent data 
-imports and transactions try to work on the same data points simultaneously. This situation can occur in both testing 
-and production environments. It's important that your code anticipates and handles these errors. 
+Conflicting transactions and serialization errors are, in a sense, the same error that usually occurs when concurrent data
+imports and transactions try to work on the same data points simultaneously. This situation can occur in both testing
+and production environments. It's important that your code anticipates and handles these errors.
 
 A common scenario that triggers an error is when two nodes in a graph are being updated by two
-different transactions attempting to add relationships between them at the same moment, changing a property, label, etc. 
+different transactions attempting to add relationships between them at the same moment, changing a property, label, etc.
 The same applies to relationships as well. In essence, it is a write-write conflict.
-For example, if both transactions try to add a relationship at the same time to 
-an identical node, the error will happen. 
+For example, if both transactions try to add a relationship at the same time to
+an identical node, the error will happen.
 
 To address these problems, consider the following strategies:
 
@@ -52,7 +52,7 @@ To address these problems, consider the following strategies:
                 tx.commit()
                 break
         except TransientError as te:
-            jitter = random.uniform(0, jitter) * initial_wait_time 
+            jitter = random.uniform(0, jitter) * initial_wait_time
             wait_time = initial_wait_time * (backoff_factor ** attempt) + jitter
             print(f"Commit failed on attempt {attempt+1}. Retrying in {wait_time} seconds...")
             time.sleep(wait_time)
@@ -62,12 +62,12 @@ To address these problems, consider the following strategies:
             raise e
   ```
 
-  Keep in mind that adjusting the `max_retries`, `initial_wait_time`, `backoff_factor`, and `jitter` is important to avoid overloading the system with retries. 
+  Keep in mind that adjusting the `max_retries`, `initial_wait_time`, `backoff_factor`, and `jitter` is important to avoid overloading the system with retries.
   For more information on how to handle retries and adjust parameters, please refer to the respective [client documentation](../../client-libraries.mdx) since examples will vary based on different clients.
 
-- **Understand the client you are using:** 
-  Neo4j clients in managed transactions have built-in logic to retry transactions that fail due to 
-  serialization errors automatically. Typically, a timeout is associated with these retries, after which 
+- **Understand the client you are using:**
+  Neo4j clients in managed transactions have built-in logic to retry transactions that fail due to
+  serialization errors automatically. Typically, a timeout is associated with these retries, after which
   the client will forward the error to the application code. Developers must be
   aware of this and implement additional error handling as required.
 
@@ -87,17 +87,17 @@ To address these problems, consider the following strategies:
 - **Avoid conflicts**: This can be done by
   implementing application-level logic to prevent concurrent transactions from
   modifying the same data points. This strategy can significantly reduce the
-  likelihood of encountering errors. It will also lead to better performance 
-  since the system is not spending time resolving conflict. 
+  likelihood of encountering errors. It will also lead to better performance
+  since the system is not spending time resolving conflict.
 
 Handling serialization errors effectively is essential for maintaining a smooth
 user experience and ensuring the reliability of your application. Implementing
 robust error handling and conflict avoidance mechanisms can mitigate the impact
 of these errors.
 
-While some client drivers may handle serialization errors by retrying transactions, 
-developers should not rely solely on this mechanism. Always include comprehensive error handling 
-in your application to address cases where the error persists beyond the retry logic. 
+While some client drivers may handle serialization errors by retrying transactions,
+developers should not rely solely on this mechanism. Always include comprehensive error handling
+in your application to address cases where the error persists beyond the retry logic.
 
 
 ## Transaction timeout
@@ -111,14 +111,15 @@ in your application to address cases where the error persists beyond the retry l
 The transaction that is running exceeds the query execution timeout that is set in the Memgraph configuration to 600 seconds by default.
 To change that, update the flag `--query-execution-timeout-sec` value to a value that is large enough to handle the transaction (query) you're running or set it to 0 for no limit.
 
-Here are the [instructions](/configuration/configuration-settings#using-flags-and-config-file) on how to update the configuration. 
+Here are the [instructions](/configuration/configuration-settings#using-flags-and-config-file) on how to update the configuration.
 
 ## Storage access timeout
 
 ### Error messages
 
 Here are the storage access error messages you might encounter:
 
+# TODO Update access types
 1. **Cannot access storage, unique access query is running. Try again later.**
 2. **Cannot get unique access to the storage. Try stopping other queries that are running in parallel.**