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

  1. 15 Oct, 2018 1 commit
  2. 10 Oct, 2018 1 commit
  3. 18 Sep, 2018 1 commit
  4. 27 Aug, 2018 2 commits
  5. 22 Aug, 2018 1 commit
  6. 16 Aug, 2018 1 commit
  7. 11 Jun, 2018 2 commits
  8. 29 May, 2018 1 commit
  9. 24 Apr, 2018 2 commits
  10. 20 Apr, 2018 1 commit
  11. 29 Mar, 2018 2 commits
  12. 23 Jan, 2018 1 commit
  13. 01 Dec, 2017 1 commit
  14. 16 Nov, 2017 2 commits
  15. 02 Nov, 2017 1 commit
    • 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)
  16. 01 Mar, 2017 3 commits
  17. 09 Jan, 2017 1 commit
  18. 21 Oct, 2016 1 commit
  19. 28 Sep, 2016 1 commit
  20. 05 Sep, 2016 4 commits
  21. 15 Jun, 2016 1 commit
  22. 14 Jun, 2016 1 commit
  23. 25 Feb, 2016 1 commit
  24. 27 Jan, 2016 1 commit
  25. 26 Jan, 2016 2 commits
  26. 15 Jan, 2016 2 commits
  27. 08 Jan, 2016 1 commit
  28. 07 Jan, 2016 1 commit