Always try to keep your transactions short and write your queries to deal with records in a deterministic order with respect to other transactions.
\nAlmost every non-trivial system needs some kind of task (job, event, whatever you call it) scheduling functionality at some point. Having more than 250 micro-services, ours was no exception.\nAt some point, it made sense to us to provide such functionality as a service for our developers. With event-store service, one simply can schedule a job to be executed at a specific time in future. There are already several ready to use tools for this specific purpose (e.g. BigBen, Quartz), however, because of several reasons (which are beyond the scope of this post) we decided to implement our own from scratch.
Considering the subject of the post which is Deadlocks, we need a brief introduction on event-store's implementation.
An event on the server side is simply a record in the database. A simplified view of events table is as follow:
| id | \nevent_type | \ndue_time | \nstart_process_time | \nend_process_time | \n
|---|---|---|---|---|
| '5c55ea79-4774-49ae-96e2-975af7a41ce6' | \n'user-cache-flush' | \n'2019-01-01 00:00:00' | \nnull | \nnull | \n
The following is a bird's-eye view of what happens on the service:
\nThread #1
\na. The service periodically fetches a bunch of unprocessed events (those that are due and have no process time, neither start nor end) from the database (and marks them as progressing by filling the start_process_time column with the current timestamp). Let's call this fetch-unprocessed query.
b. The service processes the events and marks them as processed (by filling the end_process_time column with the current timestamp). Let's call this save-processed query.
Thread #2
\na. The service periodically checks the table and looks for stale events (those that are due and have start_process_time but no end_process_time). Let's call this fetch-stale query.
b. The service marks them back as unprocessed (by setting start_process_time to null). Let's call this release-stale query.
The very first MVP was a simple read-modify-write (anti-)pattern (with the help of Spring, JPA, and Hibernate). It is not hard to guess to what issue this implementation is vulnerable: Deadlocks.
\nERROR: deadlock detected\nDetail: Process 5234 waits for ShareLock on transaction 3465; blocked by process 467845.\n Process 467845 waits for ShareLock on transaction 96575; blocked by process 5234.\nHint: See server log for query details.\nWhere: while updating tuple (14954,4) in relation \"events\"ERROR: deadlock detected\nDetail: Process 10438 waits for ExclusiveLock on tuple (14954,4) of relation 19118 of database 19113; blocked by process 31501.\n Process 31501 waits for ShareLock on transaction 763124271; blocked by process 28450.\n Process 28450 waits for ShareLock on transaction 763124277; blocked by process 28873.\n Process 28873 waits for ExclusiveLock on tuple (14954,4) of relation 19118 of database 19113; blocked by process 10438.\nHint: See server log for query details.\nWhere: while locking tuple (6984,19) in relation \"events\"In the beginning it was not a big deal, because deadlock errors were not frequent and we could live with it. However, very soon, after getting more clients, the deadlock issue (among other problems, e.g. lost-updates) started hurting the quality of the service (e.g. firing events twice).
\nFor the first attempt, we refactored the code to get rid of read-modify-write antipattern:
\n-- fetch-unprocessed query\nUPDATE events event_to_update\nSET start_process_time = now()\nFROM (\n SELECT id\n FROM events \n WHERE end_process_time is NULL\n AND start_process_time IS NULL\n AND (due_time BETWEEN ? AND ?)\n) matched_event_for_update\nWHERE event_to_update.id = matched_event_for_update.id\nRETURNING *;\n\n-- release-stale query (including fetch-stale query)\nUPDATE events event_to_release\nSET start_process_time = NULL\nFROM (\n SELECT id\n FROM events\n WHERE end_process_time IS NULL AND start_process_time < ?\n) stuck_event\nWHERE event_to_release.id = stuck_event.id\nRETURNING *;Obviously this is an improvement, though reduced the number of deadlocks, it didn't solve the issue completely.\nThe quickest solution to eliminate deadlocks was to change the isolation level to Serializable. However this is the last solution we wanted since it would hurt the performance and the quality of the service (think what would happen if one service start a transaction, fetch the events to process, but for some reason become stale).
The better way to deal with deadlock is to analyze transactions and queries to prevent transaction interference by:
\nBy the first refactoring, we made transactions a bit shorter. But there's still some room for improvement. To apply the second best practice from the above we refactored the queries as follow (essentially ordering and acquiring a lock):
\n-- fetch-unprocessed query\nUPDATE events event_to_update\nSET start_process_time = now()\nFROM (\n SELECT id\n FROM events \n WHERE ... -- as before\n ORDER BY ID\n FOR NO KEY UPDATE\n) matched_event_for_update\nWHERE ... -- as before\nRETURNING *;\n\n-- release-stale query (including fetch-stale query)\nUPDATE events event_to_release\nSET start_process_time = NULL\nFROM (\n SELECT id\n FROM events\n WHERE ... -- as before\n ORDER BY ID\n FOR NO KEY UPDATE\n) stuck_event\nWHERE ... -- as before\nRETURNING *;However, the deadlocks were still appearing intermittently:
\nERROR: deadlock detected\nDetail: Process 7534 waits for ShareLock on transaction 93897000; blocked by process 13376.\n Process 13376 waits for ShareLock on transaction 93896994; blocked by process 7534.\nHint: See server log for query details.\nWhere: while rechecking updated tuple (134131,3) in relation \"events\"Of course! we still had one transaction/query dealing with records in a non deterministic way: JpaRepository.save(Iterable<S> entities). In the code, after fetching events to be processed, we flag (UPDATE) the process events as processed, and also save (INSERT) new events spawned by the processed events. Here's the catch: the event processing is done in parallel. So the resulting list of events (both processed and newly created ones) is not ordered with respect to other transactions. So the third refactoring was to restore the order of processed events:
/**\n * To process events.\n * The result list will be ordered with respect to the given list.\n * All new events will be added at the end of the result list.\n * @param events events to be processed\n * @return list of processed and created events\n */\nprivate List<Event> doProcessEvents(List<Event> events) {\n ProcessingResult result = eventProcessor.processInParallel(events);\n\n List<Event> successfulEvents = result.getSucceeded(); // may contain new events;\n List<Event> failedEvents = result.getFailed();\n List<Event> allEvents = ListUtils.union(successfulEvents, failedEvents);\n\n Map<UUID, Integer> eventIndices = range(0, events.size()).boxed()\n .collect(CollectorUtils.toMap(i -> events.get(i).getId(), i -> i));\n\n // This should sort according to the original order and put all new events at the end.\n allEvents.sort(comparingInt(event -> eventIndices.getOrDefault(event.getId(), Integer.MAX_VALUE)));\n\n return allEvents;\n}After this last change, we saw the game for deadlocks was over: \"Goodbye Deadlock!\"
","fields":{"slug":"/event-store-deadlock/","tags":["deadlock","sql","transaction","postgresql"]}}}]}},"pageContext":{"slug":"/tags/deadlock","tag":"deadlock","categories":["Architecture","Coding","DevOps","Engineering","ProjectManagement","QA","Social","TechRadar"]}}