[jira] [Commented] (GEODE-5276) transaction commits can cause CachePerfStats entries to go negative

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

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

ASF subversion and git services commented on GEODE-5276:
--------------------------------------------------------

Commit 3cef62916627b8c87903b5044e93e0dcf8d1c465 in geode's branch refs/heads/develop from [~dschneider]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3cef629 ]

GEODE-5276: fix entries stats from going negative (#2033)

Entries was going negative during a transaction because:
* When txApplyDestroy was adding a new entry that would be a TOMBSTONE; it was setting the value of the new entry initially to Token.DESTROYED. This was wrong. It should have waited to set this until later when it knew it was in "tokenMode".
* When makeTombstone was later called it did a check to see if the entry was new. It based this in the value being Token.REMOVE_PHASE1. Since it was not (it was DESTROYED) this prevented it from doing a corrective inc of the stat to prevent it from going negative.

So the fix is the use REMOVE_PHASE1 during initialization and to only set the value of the new entry to DESTROYED if we are in tokenMode.

> transaction commits can cause CachePerfStats entries to go negative
> -------------------------------------------------------------------
>
>                 Key: GEODE-5276
>                 URL: https://issues.apache.org/jira/browse/GEODE-5276
>             Project: Geode
>          Issue Type: Bug
>          Components: transactions
>            Reporter: Darrel Schneider
>            Assignee: Darrel Schneider
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> The statistic CachePerfStats entries is a count of the number of entries in a region or cache. But the transaction code in some cases decrements it too many times causing it to go negative.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)