geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Swapnil Bawaskar <sbawas...@pivotal.io>
Subject Re: [Discuss] Enable region set operations to start JTA transactions
Date Thu, 07 Sep 2017 21:47:55 GMT
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 <mstolz@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 <agingade@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 <eshu@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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message