[jira] [Commented] (GEODE-678) DistributedLockService: reentrant lock calls with a small wait time can cause the lock to be lost

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15062963#comment-15062963 ] 

ASF subversion and git services commented on GEODE-678:
-------------------------------------------------------

Commit d31a85ff7898732857d5fd1abee8030c8beeca66 in incubator-geode's branch refs/heads/develop from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=d31a85f ]

GEODE-678: dlock reenter will no longer timeout


> DistributedLockService: reentrant lock calls with a small wait time can cause the lock to be lost
> -------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-678
>                 URL: https://issues.apache.org/jira/browse/GEODE-678
>             Project: Geode
>          Issue Type: Bug
>          Components: core
>            Reporter: Darrel Schneider
>            Assignee: Darrel Schneider
>
> If a thread already holds a lock from the DistributedLockService (this also applies to global regions and using Region.getDistributedLock) then it can reenter the lock by acquiring it again by calling lock. Since the thread already holds the lock it does not need to wait to acquire it. But if a very small waitTIme parameter is passed then the implementation may timeout the reacquire call telling the caller that it could not acquire the lock.
> In this case the thread also loses the original lock it held and future attempts to release it will fail with LockNotHeldException.
> The waitTime should only be considered in the initial lock request when you might be waiting for some other thread to release the lock. If you already hold the lock then waitTime should be ignored.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)