I tend to agree with Mike. Removing collection reads from the txn state
changes the programming model and makes it harder to write a Geode application.
We’re leaking internal details into the public behavior.
Is there another way to provide this optimization to the user? Perhaps
something like:
CacheTransactionManager txMgr = cache.getCacheTransactionManager();
txMgr.begin(READ_COMMITTED); // just thinking out loud here
Or, we could set a hard cap on the size of txState. Would that satisfy the
original goal to ensure that users apply Geode txns correctly?
Anthony
> On Feb 10, 2017, at 12:15 AM, Michael Stolz <mst...@pivotal.io> wrote:
>
> -1
>
> I would recommend against breaking repeatable read semantics for specific
> cases. If we're going to do something about the memory pressure, great, but
> not at the cost of functionality guarantees.
>
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771
>
> On Feb 9, 2017 10:29 PM, "Eric Shu" <e...@pivotal.io> wrote:
>
> All,
>
> In current Geode transaction implementation, there will be memory pressure
> if collection is used in a transaction. (GEODE-2392
> https://issues.apache.org/jira/browse/GEODE-2392).
>
> Geode transactions provide repeatable read semantics. In order to support
> this repeatable read isolation, all read operations copy the current value
> in txState.
>
> The proposed new implementation is to have collection operation in a
> transaction not copying all values into its txState. Instead, it will go
> over to region directly but reflecting the new state of the entries changed
> by the previous operations of this transaction.
>
> Please note that the proposed implementation will not support repeatable
> read for collection operations.
>
> Any thoughts?
>
> Regards,
> Eric
