geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Shu (JIRA)" <j...@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
Date Fri, 29 Sep 2017 15:01:01 GMT

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

Mime
View raw message