[ASTERIXDB-2522][TX] Skip WAIT record during lock conflicts
- user model changes: no
- storage format changes: no
- interface changes: no
Details:
- A small optimization to our deadlock-free locking potocol by skipping
the WAIT record. Once the partial frame has been flushed and previous
records are committed, the locks held by the write thread will
eventually be released by the log flusher thread. There is no need to
force the writer thread to wait for the log flusher thread.
Change-Id: I6ef3979d6393d45a6b7b2eb5f09f147299b5cd9f
Reviewed-on: https://asterix-gerrit.ics.uci.edu/3232
Sonar-Qube: Jenkins <jenkins@fulliautomatix.ics.uci.edu>
Tested-by: Jenkins <jenkins@fulliautomatix.ics.uci.edu>
Contrib: Jenkins <jenkins@fulliautomatix.ics.uci.edu>
Integration-Tests: Jenkins <jenkins@fulliautomatix.ics.uci.edu>
Reviewed-by: Murtadha Hubail <mhubail@apache.org>
diff --git a/asterixdb/asterix-transactions/src/main/java/org/apache/asterix/transaction/management/opcallbacks/PrimaryIndexModificationOperationCallback.java b/asterixdb/asterix-transactions/src/main/java/org/apache/asterix/transaction/management/opcallbacks/PrimaryIndexModificationOperationCallback.java
index 3e41264..690ef1f 100644
--- a/asterixdb/asterix-transactions/src/main/java/org/apache/asterix/transaction/management/opcallbacks/PrimaryIndexModificationOperationCallback.java
+++ b/asterixdb/asterix-transactions/src/main/java/org/apache/asterix/transaction/management/opcallbacks/PrimaryIndexModificationOperationCallback.java
@@ -62,11 +62,9 @@
* 3. if returnValue == false
* 3-1. flush all entries (which already acquired locks) to the next operator
* : this will make all those entries reach commit operator so that corresponding commit logs will be created.
- * 3-2. create a WAIT log and wait until logFlusher thread will flush the WAIT log and gives notification
- * : this notification guarantees that all locks acquired by this transactor (or all locks acquired for the entries)
- * were released.
- * 3-3. acquire lock using lock() instead of tryLock() for the failed entry
- * : we know for sure this lock call will not cause deadlock since the transactor doesn't hold any other locks.
+ * 3-2. acquire lock using lock() instead of tryLock() for the failed entry
+ * : we know for sure this lock call will not cause deadlock since the locks held by the transactor
+ * will be eventually released by the log flusher.
* 4. create an update log and insert the entry
* From the above logic, step 2 and 3 are implemented in this before() method.
**********************/
@@ -77,9 +75,6 @@
//flush entries which have been inserted already to release locks hold by them
operatorNodePushable.flushPartialFrame();
- //create WAIT log and wait until the WAIT log is flushed and notified by LogFlusher thread
- logWait();
-
//acquire lock
lockManager.lock(datasetId, pkHash, LockMode.X, txnCtx);
}
@@ -102,12 +97,4 @@
throw HyracksDataException.create(e);
}
}
-
- private void logWait() throws ACIDException {
- indexRecord.setLogType(LogType.WAIT);
- indexRecord.computeAndSetLogSize();
- txnSubsystem.getLogManager().log(indexRecord);
- // set the log type back to UPDATE for normal updates
- indexRecord.setLogType(LogType.UPDATE);
- }
}