Re: Propose a new implementation for collections in Geode transaction (GEODE-2392)
One other thing to note is that with this proposal read conflicts will also not work on reads done by collections. You enable read conflicts like so: -Dgemfire.detectReadConflicts=true On Thu, Feb 9, 2017 at 2:29 PM, Eric Shu 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 >
Re: Propose a new implementation for collections in Geode transaction (GEODE-2392)
+1.. The Geode transaction is built to work efficiently with smaller transaction...Supporting large collections in a transaction will hurt Geode performance. -Anil. On Thu, Feb 9, 2017 at 5:02 PM, Darrel Schneider wrote: > One other thing to note is that with this proposal read conflicts will also > not work on reads done by collections. > You enable read conflicts like so: -Dgemfire.detectReadConflicts=true > > On Thu, Feb 9, 2017 at 2:29 PM, Eric Shu 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 > > >
Re: Propose a new implementation for collections in Geode transaction (GEODE-2392)
+1 - I actually thought these operations didn't include the transaction state - like queries. Will this affect the way that queries operate with transactions? -Dan On Thu, Feb 9, 2017 at 6:03 PM, Anilkumar Gingade wrote: > +1.. > The Geode transaction is built to work efficiently with smaller > transaction...Supporting large collections in a transaction will hurt Geode > performance. > > -Anil. > > > On Thu, Feb 9, 2017 at 5:02 PM, Darrel Schneider > wrote: > > > One other thing to note is that with this proposal read conflicts will > also > > not work on reads done by collections. > > You enable read conflicts like so: -Dgemfire.detectReadConflicts=true > > > > On Thu, Feb 9, 2017 at 2:29 PM, Eric Shu 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 > > > > > >
Re: Propose a new implementation for collections in Geode transaction (GEODE-2392)
-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" 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
Re: Propose a new implementation for collections in Geode transaction (GEODE-2392)
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 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" 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
Re: Propose a new implementation for collections in Geode transaction (GEODE-2392)
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 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 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" 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 > >
Re: Propose a new implementation for collections in Geode transaction (GEODE-2392)
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 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 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 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" 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 >> >> >
Re: Propose a new implementation for collections in Geode transaction (GEODE-2392)
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 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 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 > 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 > 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" 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 > >> > >> > > >
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 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 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 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 >> 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 >> 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" 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 >>> >>
Re: Propose a new implementation for collections in Geode transaction (GEODE-2392)
+1 for supporting repeatable read semantics consistently. throw Unsupportedexception if some apis are not supported inside tx. -Hitesh. From: Anthony Baker 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 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 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 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 >> 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 >> 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" wrote: >>>>> >>>>> All, >>>>>
Re: Propose a new implementation for collections in Geode transaction (GEODE-2392)
>> 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 > 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 > 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 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 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
