kfaraz commented on code in PR #16393:
URL: https://github.com/apache/druid/pull/16393#discussion_r1593387274
##########
indexing-service/src/main/java/org/apache/druid/indexing/overlord/TaskLockbox.java:
##########
@@ -1271,6 +1277,108 @@ public void remove(final Task task)
}
}
+ /**
+ * Acquire a read lock to perform the segment transactional append action
for a given datasource.
+ * Throws a DruidException when acquisition fails or times out.
+ * @param task task to perform the append action
+ * @param lockAcquireTimeoutMillis milliseconds to wait for lock acquisition
+ */
+ public void acquireTransactionalAppendLock(Task task, long
lockAcquireTimeoutMillis)
+ {
+ final String datasource = task.getDataSource();
+ final ReentrantReadWriteLock readWriteLock =
+ datasourceToConcurrentLock.computeIfAbsent(datasource, ds -> new
ReentrantReadWriteLock());
+ final boolean acquired;
+ synchronized (readWriteLock) {
Review Comment:
This is better than doing `giant.lock()`. But there are still issues with it.
Let's say there is currently a read lock on this datasource held by a thread
T1, a thread T2 trying to acquire a write lock will wait inside the
synchronized block.
But that means that no more threads will be able to enter the synchronized
block, even if they were trying to acquire read locks.
We probably need to re-think this flow.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
