17.6. Creating unique nodes

17.6.1. Single thread
17.6.2. Get or create
17.6.3. Pessimistic locking

In many use cases, a certain level of uniqueness is desired among entities. You could for instance imagine that only one user with a certain e-mail address may exist in a system. If multiple concurrent threads naively try to create the user, duplicates will be created. There are three main strategies for ensuring uniqueness, and they all work across High Availability and single-instance deployments.

17.6.1. Single thread

By using a single thread, no two threads will even try to create a particular entity simultaneously. On High Availability, an external single-threaded client can perform the operations on the cluster.

17.6.2. Get or create

By using put-if-absent functionality, entity uniqueness can be guaranteed using an index. Here the index acts as the lock and will only lock the smallest part needed to guaranteed uniqueness across threads and transactions.

See Section 4.9.1, “Get or create unique node” for how to do this using the core Java API. When using the REST API, see Section 22.11, “Unique Indexes”.

17.6.3. Pessimistic locking

[Important]Important

While this is a working solution, please consider using the preferred Section 17.6.2, “Get or create” instead.

By using explicit, pessimistic locking, unique creation of entities can be achieved in a multi-threaded environment. It is most commonly done by locking on a single or a set of common nodes.

See Section 4.9.2, “Pessimistic locking for node creation” for how to do this using the core Java API.