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