[
https://issues.apache.org/jira/browse/GEODE-9757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9757:
------------------------------------
Description:
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.
was:
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 mix tx ops
with non-tx ops directly change the value stored.
A workaround to the bucket size exceptions is to make a copy of the value
before changing it.
> 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
> Priority: Major
> Labels: needsTriage
>
> 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)
