>> 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.
The reason was to support common isolation level, read-committed with pessimistic repeatable-read semantic (don't check read conflicts), and easy to write application (reduced error handling)...Also, If application wanted to have read conflicts, it could do so by reading and writing the same data back. Later we added the system property to help this scenario, we may need to re-look at it. >> In the case of non-local reads on a Partitioned Region, shouldn’t we throw a TransactionDataNotColocatedException? Yes, we throw exception for non-local read (get). But for collection apis, we don't throw exception (key set can read data from remote node), inconsistent behavior. >> 3) Some cache operations throw an UnsupportedOperationInTransactionException. Is there a reason we don’t for containsValue()? Its a overlook, one more inconsistent behavior. Based on the conversation till now: 1. Support collection apis (including containsValue()) within transaction without adding them to TX state. OR 2. Throw exception if collection APIs are invoked within TX. 1. Is what we proposing. We think supporting repeatable-read with conflict detection by default, should be treated as separate ticket. Please let us know your views, so that we can finalize on this. Thanks, -Anil. On Tue, Feb 14, 2017 at 3:04 PM, Hitesh Khamesra < hitesh...@yahoo.com.invalid> wrote: > +1 for supporting repeatable read semantics consistently. throw > Unsupportedexception if some apis are not supported inside tx. > -Hitesh. From: Anthony Baker <aba...@pivotal.io> > To: dev@geode.apache.org > Sent: Monday, February 13, 2017 8:08 AM > Subject: Re: Propose a new implementation for collections in Geode > transaction (GEODE-2392) > > 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 > >>>> > >>>> > >>> > >> > > >
