Uploaded image for project: 'Jackrabbit Content Repository'
  1. Jackrabbit Content Repository
  2. JCR-3978

Incorrect timeout value is used in the utility to synchronize modifications on a lockable node

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.11.3
    • Fix Version/s: None
    • Component/s: jackrabbit-jcr-commons
    • Labels:
      None

      Description

      There appears to be a possible error in the Locked utility class in that there is no conversion from milliseconds to seconds when a lock manager is requested for a lock for a given node (note that throughout the class, the timeout is expected to be in milliseconds). Consider the following part of the source code:

      **
      * Tries to acquire a session scoped lock on <code>lockable</code>.
      *
      * @param lockable the lockable node
      * @param isDeep   <code>true</code> if the lock should be deep
      * @param timeout  time in milliseconds to wait at most to acquire the lock.
      * @param isSessionScoped <code>true</code> if the lock is session scoped.
      * @return The <code>Lock</code> or <code>null</code> if the
      *         <code>lockable</code> cannot be locked.
      * @throws UnsupportedRepositoryOperationException
      *                             if this repository does not support locking.
      * @throws RepositoryException if an error occurs
      */
      private static Lock tryLock(Node lockable, boolean isDeep, long timeout, boolean isSessionScoped)
            throws UnsupportedRepositoryOperationException, RepositoryException {
        try {
            LockManager lm = lockable.getSession().getWorkspace().getLockManager();
            return lm.lock(lockable.getPath(), isDeep, isSessionScoped, timeout, null);
        } catch (LockException e) {
            // locked by some other session
        }
        return null;
      }
      

      As indicated in the documentation, the timeout is expected to be in milliseconds:

      time in milliseconds to wait at most to acquire the lock.

      However, when the lock manager is asked for a lock, the timeout is not converted to seconds despite the fact that documentation for the method used indicates that the timeout value is expected in seconds:

      desired lock timeout in seconds (servers are free to ignore this value); specify {@link Long#MAX_VALUE} for no timeout

      Because of this, it is very easy to get unexpected results from the org.apache.jackrabbit.util.Locked, especially for the open-scoped locks.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              illia.khokholkov Illia Khokholkov
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: