[jira] [Resolved] (GEODE-9757) a geode transaction done directly on a server that adds a value to an entry on a partitioned region does not store it in a CachedDeserializable

["Jens Deppe (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-9757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jens Deppe resolved GEODE-9757.
-------------------------------
    Fix Version/s: 1.15.0
       Resolution: Fixed

> a geode transaction done directly on a server that adds a value to an entry on a partitioned region does not store it in a CachedDeserializable 
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-9757
>                 URL: https://issues.apache.org/jira/browse/GEODE-9757
>             Project: Geode
>          Issue Type: Bug
>          Components: transactions
>            Reporter: Darrel Schneider
>            Assignee: Jens Deppe
>            Priority: Major
>              Labels: needsTriage, pull-request-available
>             Fix For: 1.15.0
>
>
> If you do a non-tx put directly on a member of a geode cluster (for example using a geode function), then the value is stored in the pr locally in a CachedDeserializable. But if you do the same op in a transaction it will store the object directly in the pr with no CachedDeserializable.
> I think the reason for this is that the original tx implementation did not support partitioned regions and on a non-pr region the local region stored the value directly. So when support was added for transactions on partitioned regions this part of the code was not customized for partitions and just used the old code.
> This can cause extra work to be done when fetching a value from the pr to send it back to a client. It can also cause bucket size exceptions if you directly change the value stored. 
> A workaround to the bucket size exceptions is to make a copy of the value before changing it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)