From e758f2ded9e02d7223c871ce5335b0fbcb1a3ae5 Mon Sep 17 00:00:00 2001 From: Reneta Popova Date: Mon, 20 Oct 2025 20:53:48 +0100 Subject: [PATCH 1/4] few editorial changes --- .../concurrent-data-access.adoc | 27 +++++++++++-------- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/modules/ROOT/pages/database-internals/concurrent-data-access.adoc b/modules/ROOT/pages/database-internals/concurrent-data-access.adoc index 08f98367d..24d8cb4ae 100644 --- a/modules/ROOT/pages/database-internals/concurrent-data-access.adoc +++ b/modules/ROOT/pages/database-internals/concurrent-data-access.adoc @@ -257,22 +257,27 @@ For these additional locks, no assumptions or guarantees can be made concerning === Locks for dense nodes -[NOTE] -==== -This _Locks for dense nodes_ section describes the behavior of the `standard`, `aligned`, and `high_limit` store formats. -The `block` format has a similar but not identical feature. -==== +When creating or deleting relationships in Neo4j, dense nodes are not exclusively locked during a transaction. +Rather, internally shared locks prevent the deletion of nodes, and shared degree locks are acquired for synchronizing with concurrent label changes for those nodes, to ensure correct count updates. -A node is considered dense if it at any point has had 50 or more relationships (i.e. it will still be considered dense even if it comes to have less than 50 relationships at any point in the future). +`standard`, `aligned`, and `high_limit` store formats:: +A node is considered dense if it, at any point, has had 50 or more relationships. +Even if it later has fewer than 50 relationships, it is still considered as dense. ++ A node is considered sparse if it has never had more than 50 relationships. -You can configure the relationship count threshold for when a node is considered dense by setting xref:configuration/configuration-settings.adoc#config_db.relationship_grouping_threshold[`db.relationship_grouping_threshold`] configuration parameter. -When creating or deleting relationships in Neo4j, dense nodes are not exclusively locked during a transaction. -Rather, internally shared locks prevent the deletion of nodes, and shared degree locks are acquired for synchronizing with concurrent label changes for those nodes to ensure correct count updates. +`block` format:: +A node is considered dense for a particular relationship type. +For example, a node can be dense for type A and sparse for type B. +A node is considered dense for a specific relationship type when it has, at one point, surpassed a certain internal size threshold, which typically happens at approximately 50 relationships of that type, but depends on the number and size of properties connected to these relationships. + +You can configure the relationship count threshold for when a node is considered dense by setting xref:configuration/configuration-settings.adoc#config_db.relationship_grouping_threshold[`db.relationship_grouping_threshold`] configuration parameter. -At commit time, relationships are inserted into their relationship chains at places that are currently uncontested (i.e. not currently modified by another transaction), and the surrounding relationships are exclusively locked. +At commit time, relationships are inserted into the backing data structures in a manner that allows concurrent modification. +For example, multiple transactions can create, update, or delete relationships connected to the same dense nodes concurrently. +This process may acquire additional exclusive locks in a sorted manner if necessary, to ensure data consistency. -In other words, relationship modifications acquire coarse-grained shared node locks when doing the operation in the transaction, and then acquire precise exclusive relationship locks during commit. +In other words, relationship modifications acquire coarse-grained shared node locks when doing the operation in the transaction, and then acquire precise exclusive locks during commit. The locking is very similar for sparse and dense nodes. The biggest contention for sparse nodes is the update of the degree (i.e. number of relationships) for the node. From 5e89b0cd5bcd549a4d20db7fc99ccd42b55a559c Mon Sep 17 00:00:00 2001 From: Reneta Popova Date: Tue, 21 Oct 2025 10:37:57 +0100 Subject: [PATCH 2/4] apply suggestions from rewview and a few more editorial updates --- .../configuration/configuration-settings.adoc | 2 +- .../concurrent-data-access.adoc | 16 ++++++++-------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/modules/ROOT/pages/configuration/configuration-settings.adoc b/modules/ROOT/pages/configuration/configuration-settings.adoc index 0ee42b37b..2319e2ab8 100644 --- a/modules/ROOT/pages/configuration/configuration-settings.adoc +++ b/modules/ROOT/pages/configuration/configuration-settings.adoc @@ -2229,7 +2229,7 @@ m|+++block+++ [frame="topbot", stripes=odd, grid="cols", cols="<1s,<4"] |=== |Description -a|Relationship count threshold for considering a node to be dense. +a|Relationship count threshold for considering a node to be dense. This setting applies only to `standard`, `aligned`, `high_limit` formats. |Valid values a|An integer that is minimum `1`. |Default value diff --git a/modules/ROOT/pages/database-internals/concurrent-data-access.adoc b/modules/ROOT/pages/database-internals/concurrent-data-access.adoc index 24d8cb4ae..23f4f579b 100644 --- a/modules/ROOT/pages/database-internals/concurrent-data-access.adoc +++ b/modules/ROOT/pages/database-internals/concurrent-data-access.adoc @@ -258,24 +258,24 @@ For these additional locks, no assumptions or guarantees can be made concerning === Locks for dense nodes When creating or deleting relationships in Neo4j, dense nodes are not exclusively locked during a transaction. -Rather, internally shared locks prevent the deletion of nodes, and shared degree locks are acquired for synchronizing with concurrent label changes for those nodes, to ensure correct count updates. +Rather, internally shared locks prevent the deletion of nodes, and shared degree locks are acquired for synchronizing with concurrent label changes for those nodes to ensure correct count updates. `standard`, `aligned`, and `high_limit` store formats:: A node is considered dense if it, at any point, has had 50 or more relationships. -Even if it later has fewer than 50 relationships, it is still considered as dense. +Even if it later has fewer than 50 relationships, it is still considered dense. + A node is considered sparse if it has never had more than 50 relationships. ++ +You can configure the relationship count threshold for when a node is considered dense by setting xref:configuration/configuration-settings.adoc#config_db.relationship_grouping_threshold[`db.relationship_grouping_threshold`] configuration parameter. `block` format:: -A node is considered dense for a particular relationship type. -For example, a node can be dense for type A and sparse for type B. -A node is considered dense for a specific relationship type when it has, at one point, surpassed a certain internal size threshold, which typically happens at approximately 50 relationships of that type, but depends on the number and size of properties connected to these relationships. - -You can configure the relationship count threshold for when a node is considered dense by setting xref:configuration/configuration-settings.adoc#config_db.relationship_grouping_threshold[`db.relationship_grouping_threshold`] configuration parameter. +A node is considered dense for a particular relationship type when it surpasses a certain internal size threshold, which typically happens at approximately 50 relationships of that type. +However, it also depends on the number and size of properties connected to these relationships. +Therefore, a node may be dense for one relationship type (e.g., A) and sparse for another (e.g., relationship type B). At commit time, relationships are inserted into the backing data structures in a manner that allows concurrent modification. For example, multiple transactions can create, update, or delete relationships connected to the same dense nodes concurrently. -This process may acquire additional exclusive locks in a sorted manner if necessary, to ensure data consistency. +This process may in rare cases acquire additional exclusive locks in a sorted manner if necessary, to ensure data consistency. In other words, relationship modifications acquire coarse-grained shared node locks when doing the operation in the transaction, and then acquire precise exclusive locks during commit. From 708d75ea5708f2f6f710947c0f6b11487928746a Mon Sep 17 00:00:00 2001 From: Reneta Popova Date: Tue, 21 Oct 2025 10:41:07 +0100 Subject: [PATCH 3/4] a few more updates --- modules/ROOT/pages/configuration/configuration-settings.adoc | 2 +- .../ROOT/pages/database-internals/concurrent-data-access.adoc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/ROOT/pages/configuration/configuration-settings.adoc b/modules/ROOT/pages/configuration/configuration-settings.adoc index 2319e2ab8..e02670b35 100644 --- a/modules/ROOT/pages/configuration/configuration-settings.adoc +++ b/modules/ROOT/pages/configuration/configuration-settings.adoc @@ -2229,7 +2229,7 @@ m|+++block+++ [frame="topbot", stripes=odd, grid="cols", cols="<1s,<4"] |=== |Description -a|Relationship count threshold for considering a node to be dense. This setting applies only to `standard`, `aligned`, `high_limit` formats. +a|Relationship count threshold for considering a node to be dense. This setting applies only to `standard`, `aligned`, and `high_limit` formats. |Valid values a|An integer that is minimum `1`. |Default value diff --git a/modules/ROOT/pages/database-internals/concurrent-data-access.adoc b/modules/ROOT/pages/database-internals/concurrent-data-access.adoc index 23f4f579b..65634458f 100644 --- a/modules/ROOT/pages/database-internals/concurrent-data-access.adoc +++ b/modules/ROOT/pages/database-internals/concurrent-data-access.adoc @@ -258,7 +258,7 @@ For these additional locks, no assumptions or guarantees can be made concerning === Locks for dense nodes When creating or deleting relationships in Neo4j, dense nodes are not exclusively locked during a transaction. -Rather, internally shared locks prevent the deletion of nodes, and shared degree locks are acquired for synchronizing with concurrent label changes for those nodes to ensure correct count updates. +Rather, internally shared locks prevent the deletion of nodes and shared degree locks are acquired for synchronizing with concurrent label changes for those nodes to ensure correct count updates. `standard`, `aligned`, and `high_limit` store formats:: A node is considered dense if it, at any point, has had 50 or more relationships. From 1201ddc5dd0fe9f0dd41a1f16463791df2960e64 Mon Sep 17 00:00:00 2001 From: Reneta Popova Date: Tue, 21 Oct 2025 10:56:48 +0100 Subject: [PATCH 4/4] a few more updates --- .../database-internals/concurrent-data-access.adoc | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/modules/ROOT/pages/database-internals/concurrent-data-access.adoc b/modules/ROOT/pages/database-internals/concurrent-data-access.adoc index 65634458f..006505b04 100644 --- a/modules/ROOT/pages/database-internals/concurrent-data-access.adoc +++ b/modules/ROOT/pages/database-internals/concurrent-data-access.adoc @@ -257,19 +257,17 @@ For these additional locks, no assumptions or guarantees can be made concerning === Locks for dense nodes -When creating or deleting relationships in Neo4j, dense nodes are not exclusively locked during a transaction. +When creating or deleting relationships, Neo4j does not exclusively lock dense nodes during a transaction. Rather, internally shared locks prevent the deletion of nodes and shared degree locks are acquired for synchronizing with concurrent label changes for those nodes to ensure correct count updates. `standard`, `aligned`, and `high_limit` store formats:: A node is considered dense if it, at any point, has had 50 or more relationships. -Even if it later has fewer than 50 relationships, it is still considered dense. -+ -A node is considered sparse if it has never had more than 50 relationships. -+ +Even if it later has fewer than 50 relationships, it is still considered dense. + +A node is considered sparse if it has never had more than 50 relationships. + You can configure the relationship count threshold for when a node is considered dense by setting xref:configuration/configuration-settings.adoc#config_db.relationship_grouping_threshold[`db.relationship_grouping_threshold`] configuration parameter. `block` format:: -A node is considered dense for a particular relationship type when it surpasses a certain internal size threshold, which typically happens at approximately 50 relationships of that type. +A node is considered dense for *a particular relationship type* when it surpasses a certain internal size threshold, which typically happens at approximately 50 relationships of that type. However, it also depends on the number and size of properties connected to these relationships. Therefore, a node may be dense for one relationship type (e.g., A) and sparse for another (e.g., relationship type B). @@ -277,7 +275,7 @@ At commit time, relationships are inserted into the backing data structures in a For example, multiple transactions can create, update, or delete relationships connected to the same dense nodes concurrently. This process may in rare cases acquire additional exclusive locks in a sorted manner if necessary, to ensure data consistency. -In other words, relationship modifications acquire coarse-grained shared node locks when doing the operation in the transaction, and then acquire precise exclusive locks during commit. +In other words, relationship modifications acquire coarse-grained shared node locks when doing the operation in the transaction, and then acquire precise exclusive locks during the commit. The locking is very similar for sparse and dense nodes. The biggest contention for sparse nodes is the update of the degree (i.e. number of relationships) for the node.