As Eric mentioned, this will address the current inconsistencies in the product and will provide consistent behavior with replicated and partitioned region.
Also, if we look into typical database transaction applications, the transaction queries doesn't touch/read all the records in the table, mostly or always they are targeted queries (with where clause) with small result set. In Geode case, without support for any filtering option with collection api's, it may have to bring in all the region entries into the Tx state, which application may not be looking for...The better solution to support this is by making Geode queries transactional; which can provide repeatable read semantic on sub-set data. I agree, its hard for application to distinguish what apis are part of Tx and what is not...Option to address this could be, proper documentation or not allowing collection apis inside the Tx. In needed, application has to suspend the Tx, to call them. -Anil. On Fri, Feb 10, 2017 at 10:57 AM, Eric Shu <e...@pivotal.io> wrote: > Hi Dan, > > Currently query results do not reflect transaction state at all. The new > proposal won't change that. > > On Fri, Feb 10, 2017 at 10:47 AM, Eric Shu <e...@pivotal.io> wrote: > > > 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 > >> > >> > > >
