You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Swapnil Bawaskar <sb...@pivotal.io> on 2017/09/07 21:47:55 UTC
Re: [Discuss] Enable region set operations to start JTA transactions
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 <ms...@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 <ag...@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 <es...@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
> > >
> >
>
Re: [Discuss] Enable region set operations to start JTA transactions
Posted by Eric Shu <es...@pivotal.io>.
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 repeatable read on the non transactional data).
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?
Answer: I agree totally with this approach (basically set operations will
only iterate through non transactional data -- non repeatable read).
However, this approach was rejected from community to favor backwards
compatibility.
Regards,
Eric
On Thu, Sep 7, 2017 at 2:47 PM, Swapnil Bawaskar <sb...@pivotal.io>
wrote:
> 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 <ms...@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 <ag...@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 <es...@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
> > > >
> > >
> >
>