+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
> >
>

Reply via email to