[
https://issues.apache.org/jira/browse/GEODE-9757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435036#comment-17435036
]
ASF subversion and git services commented on GEODE-9757:
--------------------------------------------------------
Commit e0c33cd80e66ffcdcfa99ea7cc8d0dbcf9aa8ca1 in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e0c33cd ]
GEODE-9757: Ensure that tx cache ops always add CachedDeserializable entries
(#7022)
- 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.
- The reason for this is probably 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 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)
