Please note even in our current transaction implementation, repeatable read is not supported on collection operation in transaction with Partitioned Region. Currently, only the local entry set (resides in the local node) of a PR is copied into the txState, while data on the remote nodes are not. Another call of the collection operation of the same transaction could have different results for the data on the remote nodes.
In addition, containValue() call currently does not support repeatable read either. It does not copy all data into txState (replicated or partitioned regions.) Currently we only support limited repeatable read for collection operations in transaction (at least for PR). On Fri, Feb 10, 2017 at 8:36 AM, Anthony Baker <aba...@pivotal.io> wrote: > 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 > >
