GemFire Transactions and Non-Transactional Operations on the Same Keys
search cancel

GemFire Transactions and Non-Transactional Operations on the Same Keys

book

Article ID: 398311

calendar_today

Updated On:

Products

VMware Tanzu Gemfire

Issue/Introduction

GemFire does not support using transactions and performing non-transactional operations on the same keys at the same time

Environment

All supported versions of Tanzu GemFire

 

Cause

Transactions and non-transactional operations use different concurrency control mechanisms in GemFire. For performance reasons, non-transactional operations do not acquire the exclusive locks that transactions use to check for conflicts. As a result, a transaction cannot detect conflicts caused by non-transactional operations on the same data


Concurrency and Locking:

  • Both transactional and non-transactional operations use locks on the primary bucket to handle concurrent updates.
  • However, the locks used by transactions are distinct from those used by non-transactional operations. Transaction-related locks do not guard against non-transactional operations, and vice versa


Risk of Inconsistency:


Mixing transactional and non-transactional operations on the same key can result in updates being applied in different orders on primary and secondary copies. This can leave the data in an inconsistent state across replicas


Example Scenario:


Consider the following sequence of events, which demonstrates how mixing transactional and non-transactional operations on the same key can lead to data inconsistency:

  • Thread A begins to commit a transaction that updates a key to value V1.
  • Thread A applies V1 to the primary copy.
  • Thread B, in parallel, performs a non-transactional put that updates the same key to value V2.
  • Thread B applies V2 to both the primary and secondary copies.
  • Thread A’s transaction then applies V1 to the secondary copy, overwriting V2.

After these operations:

  • The primary copy holds value V2.
  • The secondary copy holds value V1.
  • This results in inconsistent data between the primary and secondary, as the order of updates is not guaranteed due to the different locking mechanisms used by transactional and non-transactional operations

Resolution


For data consistency, ensure that each key is modified either exclusively by transactions or exclusively by non-transactional operations. Do not mix both operation types on the same key

For further details and design recommendations, see the Design Considerations section of the GemFire documentation

Additional Information