geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (GEODE-4033) TxFailover doesn't throw exception when tx state is not found on the server
Date Fri, 01 Dec 2017 20:35:00 GMT


ASF GitHub Bot commented on GEODE-4033:

agingade opened a new pull request #1115: GEODE-4033: Exception is thrown when Tx Id is not
found on server dur…
   …ing failover
   Thank you for submitting a contribution to Apache Geode.
   In order to streamline the review of the contribution we ask you
   to ensure the following steps have been taken:
   ### For all changes:
   - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
   - [ ] Has your PR been rebased against the latest commit within the target branch (typically
   - [ ] Is your initial contribution a single, squashed commit?
   - [ ] Does `gradlew build` run cleanly?
   - [ ] Have you written or updated unit tests to verify your changes?
   - [ ] If adding new dependencies to the code, are these dependencies licensed in a way
that is compatible for inclusion under [ASF 2.0](
   ### Note:
   Please ensure that once the PR is submitted, you check travis-ci for build issues and
   submit an update to your PR as soon as possible. If you need help, please send an
   email to

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

> TxFailover doesn't throw exception when tx state is not found on the server
> ---------------------------------------------------------------------------
>                 Key: GEODE-4033
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: transactions
>            Reporter: Anilkumar Gingade
>            Assignee: Anilkumar Gingade
> When a client transaction gets an exception due to connection failure; it tries to execute
the transaction on other available server. This failover transaction is processed, if the
tx.state is available on any of the servers; if not an exception thrown back to the client.

> Currently the client catches this exception and tries to re-create the exception instead
of returning back to the application. This could cause multiple transaction state to be created
for the same transaction id on the cluster (if the first attempt to the server is still in
process), causing unexpected behavior.

This message was sent by Atlassian JIRA

View raw message