[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GitHub] brooklyn-server pull request #966: Persistence efficient: unchanged and tran...

Github user aledsage commented on a diff in the pull request:

    --- Diff: core/src/main/java/org/apache/brooklyn/core/mgmt/persist/StoreObjectAccessorLocking.java ---
    @@ -225,6 +225,21 @@ public void waitForCurrentWrites(Duration timeout) throws InterruptedException,
    +    @Override
    +    public boolean isWriting() {
    +        try {
    +            boolean locked = lock.readLock().tryLock(0, TimeUnit.MILLISECONDS);
    --- End diff --
    I don't think so - if another thread holds a read lock, then this thread will be able to acquire the read lock at the same time (sharing it with an unlimited number of readers). However, if another thread has a write lock then the attempt to immediately get a read lock will fail.
    The `lock` field is a `ReentrantReadWriteLock` in "fair mode" for lock acquisition. That means the read-lock acquisition will also fail if there is a queued write-lock request.