[
https://issues.apache.org/jira/browse/GEODE-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16412273#comment-16412273
]
ASF subversion and git services commented on GEODE-4928:
--------------------------------------------------------
Commit f3b47a5a8ba65fbcf0915e94da3ef3683962c43a in geode's branch
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f3b47a5 ]
GEODE-4928 DistributedLockService doesn't work as expected while the dlock
grantor is initialized
The lock service cleans up transaction locks in a background thread but
cleans up regular dlocks in its membership listener. This allows you to
get a dlock as soon as a member holding that lock leaves the distributed
system, but its transaction locks stick around for a while.
The fix for this is to wait for the background processing to complete before
acquiring locks and checking for conflicts.
> DistributedLockService doesn't work as expected while the dlock grantor is
> initialized
> --------------------------------------------------------------------------------------
>
> Key: GEODE-4928
> URL: https://issues.apache.org/jira/browse/GEODE-4928
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service
> Reporter: Bruce Schuchardt
> Assignee: Bruce Schuchardt
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I wrote a function that obtained a dlock and then performed a transaction.
> It always operates on the same dlock key and the same keys in my region.
> That protects against getting a commit conflict exception BUT this sometimes
> fails if the JVM holding the lock crashes. One of the functions appears to
> get the dlock okay but then its transaction fails when it goes to commit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
