How is this going to work for a PartitionedRegion? Are we going to throw TransactionDataNotColocatedException when iterating over non-colocated data in the PR? If so, how useful is this work going to be if the set ops always throw exceptions? If not, then that will mean we have to maintain a txState on all the members of the system. This effectively means supporting distributed transactions.
At this point, I would like to question the ability to perform set ops from within a transaction. We already do not allow region operations (clear, destroy etc) from within a transaction, should we disable set ops (entries(), keys()) etc as well? On Mon, Aug 28, 2017 at 9:27 AM Michael Stolz <mst...@pivotal.io> wrote: > +1 for revising set ops to bootstrap by default. Document the behavior > change in release notes along with property to revert to old behavior. > > -- > Mike Stolz > Principal Engineer, GemFire Product Manager > Mobile: +1-631-835-4771 <(631)%20835-4771> > > On Fri, Aug 25, 2017 at 6:41 PM, Anilkumar Gingade <aging...@pivotal.io> > wrote: > > > +1 Having a consistent behavior for set operation within the transaction > > (wherever its invoked). And having a gemfire property to allow old way. > > > > On Fri, Aug 25, 2017 at 2:49 PM, Eric Shu <e...@pivotal.io> wrote: > > > > > Hi Team, > > > > > > Currently in GEODE JTA implementation, if GEODE transaction is not yet > > > bootstrapped (there is no TXState created yet for the transaction), > > region > > > set operations will not bootstrap the JTA transaction. In other word, > if > > > the first operation of the JTA transaction is region set operation, the > > set > > > is not in a transactional view (TXState). However, if the JTA > > > UserTransaction has been bootstrapped (first operation is a get or put > > > operation, etc), the following region set operation is transactional > (in > > > TXState). To some users, this seems to be a bug. Please see the GEODE > > > ticket (https://issues.apache.org/jira/browse/GEODE-3521). > > > > > > Although we intentionally implemented this way to alleviate the memory > > > requirements for users (each transaction will have a new copy of region > > > data put into TXState but not if the set op is the first op), we think > > the > > > new user has a valid point as well. We propose to allow region set op > to > > > bootstrap the transaction. To allow backward compatibility, we will > > > introduce a new GemFire property to allow the old behavior. > > > > > > The question is what should be a default behavior. Do we allow region > set > > > op to bootstrap transaction as default? If so, existing customers need > to > > > set the new property to get the old behavior. Or we maintain the old > > > behavior, and require the new users to set the property. > > > > > > Please comment if you have any suggestions. > > > > > > Thanks, > > > Eric > > > > > >
