is currently readonly. We are migrating to, please continue working there on Monday 14/12. See:

  • Ate Douma's avatar
    CMS-10974 [Backport 11.2] Add Lock Service through which you can acquire a... · d7e16b2c
    Ate Douma authored
    CMS-10974 [Backport 11.2] Add Lock Service through which you can acquire a (cluster wide) lock (without using JCR)
    This is a single squashed commit backport from CMS-10897 and CMS-10970:
      CMS-10897 Added Lock Manager Service interface.
        (cherry picked from commit c896f52c)
      CMS-10897 Also store the lock thread in Lock object
        (cherry picked from commit 5eb8911b)
      CMS-10897 Add refreshRateSeconds concept
        (cherry picked from commit 5993979a)
      CMS-10897 Improve the javadoc
        (cherry picked from commit a2b2c5b8)
      CMS-10897 Don't throw LockException on a couple of methods
        Otherwise typically end projects have to try / catch again in finally
        block where they invoke #unlock
        (cherry picked from commit 669db680)
      CMS-10897 remove pointless RuntimeException javadoc mention
        The lock manager impl shouldn't throw a runtime exception but
        just log a warning or error in case something completely unexpected
        happens (like failing database connection)
        (cherry picked from commit 7fafe01a)
      CMS-10897 introduce LockManagerException for some methods
        For a method like #isLocked or #getLocks, in case of an exception, we
        need to throw an exception: Otherwise we need to return true|false or
        an empty list: Client code can't handle this right. Then we can choose
        between a runtime or checked exception. Since something like #getLocks
        is something a client can react on (for example show a failed message in
        UI for lock overview or a retry), a checked exception makes most sense
        (cherry picked from commit b13f6b91)
      CMS-10897 Remove the #lock with refreshRateSeconds
        In practice, it is never needed. The LockManager will just refresh the
        locks within 60 seconds. There is no real added value in having this
        method apart from an extremely tiny optimization (that refresh can
        be invoked less frequently)
        (cherry picked from commit af558c5a)
      CMS-10897 Introduce LockResource such that we can use try-with-resource
        (cherry picked from commit 401c0fb2)
      CMS-10897 Add a reference to the Lock and Thread in the LockResource
        These fields make sense to expose in the LockResource
        (cherry picked from commit e752a434)
      CMS-10897 adding LockManagerUtils to support waiting for a lock
        Unit test will be provided through hippo-repository/test module
        (cherry picked from commit f1e8869a)
      CMS-10897 Make javadoc more explicit
       (cherry picked from commit d56dcc01)
      CMS-10897 Javadoc fix and throw IllegalStateException in error scenario
        Although it can't happen, returning null is odd imho. There is obviously
        an illegal state, so let's throw one
        (cherry picked from commit de44f55d)
      CMS-10897 Describe the LockManagerUtils in the javadoc as well
        Explain the difference between LockManager and ReentrantLock and
        explain how the cluster wide ReentrantLock behavior can be achieved
        with the LockManagerUtils
        (cherry picked from commit f4062c4b)
      CMS-10897 improve javadoc
        (cherry picked from commit b0a3ac98)
      CMS-10970 Support closing a LockResource by a different thread
        (cherry picked from commit 9c40d9da)
    (cherry picked from commit b00702b1)
.gitignore 64 Bytes