geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anilkumar Gingade <aging...@pivotal.io>
Subject Re: [Discuss] Enable region set operations to start JTA transactions
Date Fri, 25 Aug 2017 22:41:54 GMT
+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