Skip to content

Commit 501a81a

Browse files
Merge branch 'dev' into cit-retry-note
2 parents 9b1072f + b367856 commit 501a81a

File tree

1 file changed

+25
-1
lines changed

1 file changed

+25
-1
lines changed

modules/ROOT/pages/subqueries/subqueries-in-transactions.adoc

Lines changed: 25 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -958,7 +958,7 @@ CALL (row) {
958958
MERGE (y:Year {year: row.year})
959959
MERGE (m)-[r:RELEASED_IN]->(y)
960960
} IN 2 CONCURRENT TRANSACTIONS OF 10 ROWS ON ERROR RETRY FOR 3 SECONDS THEN CONTINUE REPORT STATUS AS status
961-
RETURN status.transactionID as transaction, status.committed AS successfulTransaction
961+
RETURN status.transactionId as transaction, status.committed AS successfulTransaction
962962
----
963963
// end::subqueries_in_transactions_deadlock_example[]
964964
@@ -1066,6 +1066,30 @@ The result shows that all transactions are now successful:
10661066
+-------------------------------------------------+
10671067
----
10681068
1069+
Deadlock resolution and transaction retries are time-consuming, making deadlock avoidance a preferred strategy.
1070+
This can be achieved by dividing a task into two distinct subqueries: a data-independent subquery run in parallel with maximum concurrency, and a data-dependent subquery executed serially (i.e. one transaction at a time) to avoid deadlocks.
1071+
In the below example, nodes and properties are created in a concurrent subquery, while the relationships connecting those nodes are created in a serial subquery.
1072+
This method benefits from the performance of concurrent transactions while avoiding deadlocks.
1073+
1074+
.Avoiding deadlocks by dividing an import task into a data-independent concurrent subquery followed by a data-dependent serial subquery
1075+
// tag::subqueries_in_transactions_deadlock_example_2[]
1076+
[source, cypher]
1077+
----
1078+
LOAD CSV WITH HEADERS FROM 'https://data.neo4j.com/importing-cypher/movies.csv' AS row
1079+
CALL (row) {
1080+
MERGE (m:Movie {movieId: row.movieId})
1081+
MERGE (y:Year {year: row.year})
1082+
RETURN m, y
1083+
} IN CONCURRENT TRANSACTIONS OF 10 ROWS ON ERROR RETRY THEN CONTINUE REPORT STATUS AS nodeStatus
1084+
CALL (m, y) {
1085+
MERGE (m)-[r:RELEASED_IN]->(y)
1086+
} IN TRANSACTIONS OF 10 ROWS ON ERROR RETRY THEN CONTINUE REPORT STATUS AS relationshipStatus
1087+
RETURN nodeStatus.transactionId as nodeTransaction,
1088+
nodeStatus.committed AS successfulNodeTransaction,
1089+
relationshipStatus.transactionId as relationshipTransaction,
1090+
relationshipStatus.committed AS successfulRelationshipTransaction
1091+
----
1092+
// end::subqueries_in_transactions_deadlock_example_2[]
10691093
10701094
.Click to see an example of failed transactions being retried without using `ON ERROR RETRY`
10711095
[%collapsible]

0 commit comments

Comments
 (0)