+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 <aging...@pivotal.io> 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 <dschnei...@pivotal.io> > 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 <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 > > > > > >
