How is this going to work for a PartitionedRegion?
Answer: This will not be changed from current implementation -- transaction
host will copy all primary data (on the node) to its TXState, and will
iterate through remaining data (on other nodes) as non transactional data
(not able to support repea
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 txSta
+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
wrote:
> +1 Having a
+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 wrote:
> Hi Team,
>
> Currently in GEODE JTA implementation, if GEODE transaction is not yet
> bootstrapped (
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, th
