Questions: 1) Do you know why we don’t set detectReadConflicts [1] true by default? I would guess that most users would not expect dirty reads in the context of a repeatable read isolation level. 2) In the case of non-local reads on a Partitioned Region, shouldn’t we throw a TransactionDataNotColocatedException? 3) Some cache operations throw an UnsupportedOperationInTransactionException. Is there a reason we don’t for containsValue()?
Anthony [1] https://geode.apache.org/docs/guide/developing/transactions/transaction_semantics.html > On Feb 10, 2017, at 12:23 PM, Anilkumar Gingade <aging...@pivotal.io> wrote: > > 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 >>>> >>>> >>> >>
