{"id":2027,"date":"2025-11-28T15:58:06","date_gmt":"2025-11-28T14:58:06","guid":{"rendered":"https:\/\/www.loicmathieu.fr\/wordpress\/fr\/?p=2027"},"modified":"2025-12-12T10:26:54","modified_gmt":"2025-12-12T09:26:54","slug":"implementing-a-lock-in-elasticsearch","status":"publish","type":"post","link":"https:\/\/www.loicmathieu.fr\/wordpress\/informatique\/implementing-a-lock-in-elasticsearch\/","title":{"rendered":"Implementing a lock in Elasticsearch"},"content":{"rendered":"

At Kestra<\/a>, the workflow orchestration and scheduling platform I work for, we have two repository implementations: JDBC (with support for H2, MySQL, and Postgres) and Elasticsearch.<\/p>\n

In JDBC, locking a record for processing is fairly easy:<\/p>\n

    \n
  1. SELECT FOR UPDATE ... WHERE ...<\/code> will place a lock on the record(s)<\/li>\n
  2. We process the record(s) in the same transaction<\/li>\n
  3. UPDATE...<\/code><\/li>\n<\/ol>\n

    At the end of the transaction, the database will automatically release the locks obtained via SELECT FOR UPDATE<\/code>.<\/p>\n

    But Elasticsearch does not support locks or transactions. Is there a way to simulate a lock?<\/p>\n

    Index vs Doc API<\/h2>\n

    Elasticsearch is both a NoSQL database and a search engine.\nLike any search engine, it relies on an asynchronous indexing phase.<\/p>\n

    This has two consequences:<\/p>\n

      \n
    1. A search may not return an existing document.<\/li>\n
    2. Indexing will overwrite any existing documents by default.<\/li>\n<\/ol>\n

      There are two solutions to overcome this:<\/p>\n

        \n
      1. Use the Doc API to load a document from its ID instead of performing a search. For this to work, you must set the document ID when indexing it and not let Elasticsearch defines an ID for you.<\/li>\n
      2. When creating a lock, use opType: Create<\/code> to ensure that no document exists for the same ID. This prevents a record from being created between the time you check whether a lock exists and the time you create the lock document.<\/li>\n<\/ol>\n

        LockRepository<\/h2>\n

        Here is a potential implementation for a Lock CRUD repository:<\/p>\n

        \npublic Optional findById(String category, String id)  throws IOException {\n        GetRequest getRequest = new GetRequest.Builder()\n                .index(\"locks\")\n                .id(id)\n                .build();\n\n        GetResponse getResponse = client.get(getRequest, Lock.class);\n        return Optional.ofNullable(getResponse.source());\n}\n\npublic boolean create(Lock newLock) throws IOException {\n        try {\n                \/\/ we use OptType.Create, so if a doc already exists, it will refuse to index a new one.\n                IndexRequest request = new IndexRequest.Builder()\n                        .index(\"locks\")\n                        .id(newLock.uid())\n                        .document(newLock)\n                        .opType(OpType.Create)\n                        .build();\n                client.index(request);\n                return true;\n        } catch (IOException e) {\n                \/\/ for conflicts, we return false to indicate that we were not able to create the lock\n                if (e instanceof ResponseException respException && \n                                respException.getResponse().getStatusLine().getStatusCode() == 409) {\n                        return false;\n                }\n                throw e;\n        }\n}\n\npublic void deleteById(String category, String id) throws IOException {\n        DeleteRequest request = new DeleteRequest.Builder()\n                .index(\"locks\")\n                .id(IdUtils.fromParts(category, id))\n                .build();\n\n        client.delete(request);\n}\n<\/pre>\n
        LockService<\/h2>\n
        We will now implement a LockService<\/code> that allows the execution of a Runnable<\/code> guarded by a lock to simulate a transaction.<\/p>\n
        The principle is as follows:<\/p>\n