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