[
https://issues.apache.org/jira/browse/GEODE-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589446#comment-16589446
]
ASF subversion and git services commented on GEODE-5376:
--------------------------------------------------------
Commit 71c8a69a851788bc79a62e4d618a05fe68886e92 in geode's branch
refs/heads/feature/GEODE-5376 from eshu
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=71c8a69 ]
GEODE-5376: Move SynchronizationRunnable to TXState
Different threads can handle JTA beforeCompletion and afterCompletion after
client failover.
Use TXStateSynchronizationRunnable to handle this case.
> In JTA, Geode afterCompletion may fail even though the JTA host still
> available
> -------------------------------------------------------------------------------
>
> Key: GEODE-5376
> URL: https://issues.apache.org/jira/browse/GEODE-5376
> Project: Geode
> Issue Type: Bug
> Components: transactions
> Affects Versions: 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0
> Reporter: Eric Shu
> Assignee: Eric Shu
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> When JTA is hosted on a server S2, and there is another server S1 handles the
> client JTA request. After the S1 executed JTA beforeCompletion initiated from
> client, the S2's P2P reader thread for S1 will hold the locks for the JTA. If
> at the time, S1 is lost/shut down, client will failover to another server to
> try afterCompletion. The afterCompletion attempt will fail as the new thread
> does not hold the lock. This will cause the client JTA to fail due to
> CommitConflict, even though there is not concurrent commit operations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)