Mailing-List: contact issues-help@geode.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geode.apache.org
Date: Fri, 29 Sep 2017 15:01:01 +0000 (UTC)
From: "Eric Shu (JIRA)" <jira@apache.org>
To: issues@geode.apache.org
Message-ID: <JIRA.13104083.1506027749000.236921.1506697261671@Atlassian.JIRA>
In-Reply-To: <JIRA.13104083.1506027749000@Atlassian.JIRA>
References: <JIRA.13104083.1506027749000@Atlassian.JIRA> <JIRA.13104083.1506027749928@jira-lw-us.apache.org>
Subject: [jira] [Commented] (GEODE-3679) Server node should forward client
 member id to other partition nodes even if it already has a TXState
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 29 Sep 2017 15:01:07 -0000


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

Eric Shu commented on GEODE-3679:
---------------------------------

The fix reveals another issue in region.size() call in transaction. Will provide a fix of this as well.

When a server starts transaction with PeerTXStateStub, (TXState resides on another server), it will send partitioned region.entryCount to the server hosting the tx. The hosting server gets size info of all the buckets from itself and all other nodes.

Currently when the first server receive the request for size, it will go through the code path and sending the request back to the hosting server to get the size. This leads to the actual size information from the buckets it hosts to be lost.

> Server node should forward client member id to other partition nodes even if it already has a TXState
> -----------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-3679
>                 URL: https://issues.apache.org/jira/browse/GEODE-3679
>             Project: Geode
>          Issue Type: Bug
>          Components: transactions
>    Affects Versions: 1.1.0, 1.2.0, 1.3.0
>            Reporter: Eric Shu
>            Assignee: Eric Shu
>
> If the server starts the transaction from client with TXId(clientMember, uniqueId) and bootstrap a TXState as its realDeal, it should still forward the tx originating member to other nodes in a PartitionMessage as long as these msg can not start a new transaction ie FetchKeysMessage. 
> Otherwise, the receiving side will construct a transaction with TXId using the server memberId. There could be a case that the server did initiate a real transaction using the same uniqueId. This will cause problem, and other partition node may not process these message as the transaction may be already finished.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)