From c4a6057b8f4998a81bd60b1e690702ac8b821a62 Mon Sep 17 00:00:00 2001
From: Valery Kharseko <vharseko@3a-systems.ru>
Date: Fri, 02 Oct 2026 08:58:19 +0000
Subject: [PATCH] [#1149] Replay a rolled back PDB transaction until its conflict clears, bounded only by an optional db-txn-retry-time-limit (#1152)
---
opendj-server-legacy/src/main/java/org/opends/server/backends/pluggable/spi/Storage.java | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/opendj-server-legacy/src/main/java/org/opends/server/backends/pluggable/spi/Storage.java b/opendj-server-legacy/src/main/java/org/opends/server/backends/pluggable/spi/Storage.java
index 2164d2e..5883786 100644
--- a/opendj-server-legacy/src/main/java/org/opends/server/backends/pluggable/spi/Storage.java
+++ b/opendj-server-legacy/src/main/java/org/opends/server/backends/pluggable/spi/Storage.java
@@ -75,10 +75,12 @@
/**
* Executes a write operation. In case of a write operation rollback, implementations may replay the write
* operation rather than propagate the failure: a {@link WriteOperation} is required to be idempotent for
- * exactly that reason. A replay must be bounded - by a number of attempts, by a window of time, or by both -
- * so that a conflict which does not clear reaches the caller instead of being retried forever. The pluggable
- * backend holds locks across this method, up to the exclusive lock of an entry container, and every thread
- * waiting on one of those locks waits for as long as this method does.
+ * exactly that reason. A replay may be bounded - by a number of attempts, by a window of time, or by both - so
+ * that a conflict which does not clear reaches the caller, or may go on for as long as the conflict lasts, the
+ * way a writer of a lock based engine waits for a lock; an engine which resolves every conflict by a rollback
+ * should bound it by time only, since a healthy write under concurrent load loses several in a row. The
+ * pluggable backend holds locks across this method, up to the exclusive lock of an entry container, and every
+ * thread waiting on one of those locks waits for as long as this method does.
* <p>
* A caller that mutates state around this method must handle that bound being spent. Removing an entry from an
* in-memory map before the write so that a replay still finds the work to do, or reading configuration back out
--
Gitblit v1.10.0