[
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)
