From 8a4ac6511b25e8bd3bd186a901b324b56ad51069 Mon Sep 17 00:00:00 2001 From: gbrodman Date: Tue, 19 Oct 2021 11:36:15 -0400 Subject: [PATCH] Use READ_COMMITTED serialization level in CreateSyntheticHEA (#1395) I observed an instance in which a couple queries from this action were, for whatever reason, hanging around as idle for >30 minutes. Assuming the behavior that we saw before where "an open idle serializable transaction means all pg read-locks stick around forever" still holds, that's the reason why the amount of read-locks in use spirals out of control. I'm not sure why those queries aren't timing out, but that's a separate issue. --- .../javascrap/CreateSyntheticHistoryEntriesAction.java | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/core/src/main/java/google/registry/tools/javascrap/CreateSyntheticHistoryEntriesAction.java b/core/src/main/java/google/registry/tools/javascrap/CreateSyntheticHistoryEntriesAction.java index ed90d0a79..2941a5e0c 100644 --- a/core/src/main/java/google/registry/tools/javascrap/CreateSyntheticHistoryEntriesAction.java +++ b/core/src/main/java/google/registry/tools/javascrap/CreateSyntheticHistoryEntriesAction.java @@ -108,6 +108,16 @@ public class CreateSyntheticHistoryEntriesAction implements Runnable { return jpaTm() .transact( () -> { + // Use READ COMMITTED isolation level so that any long-living queries don't cause + // collection of predicate locks to spiral out of control (as would happen with a + // SERIALIZABLE isolation level) + // + // NB: setting the isolation level inside the transaction only works for Postgres and + // will be reverted to the default once the transaction is committed. + jpaTm() + .getEntityManager() + .createNativeQuery("SET TRANSACTION ISOLATION LEVEL READ COMMITTED") + .executeUpdate(); // The class we're searching from is based on which parent type (e.g. Domain) we have Class historyClass = getHistoryClassFromParent(resource.getClass());