Skip to main content
Aerospike Vector opens new approaches to AI-driven recommendationsWebinar registration

Multi-record transactions

This page describes Aerospike's multi-record transaction (MRT) feature.

Overview​

An MRT can guarantee one of two outcomes: either all commands succeed together, or one or more commands fail, in which case you can request to roll back to the state of the records prior to the attempted MRT. AThe MRT provides isolation,that is, no commands outside the transaction can see the state changes being created inside the transaction. This allows you to enforce serializability requirements by putting all requests with such requirements into their own MRTs.

Supported operations and commands​

  • All single record operations
  • All batch operations

Un-supported operations and commands​

  • info commands
  • truncate
  • scans
  • queries

Frequently asked questions​

What do I need to know about read operations?​

  • Read operations can influence a transaction and therefore can be included.
  • Read operations in a multi-record transaction must have their policy.txn parameter set.

What elements need a transaction ID?​

  • client.exists()
  • BatchPolicy txn field in the batch client.get() or client.operate()

How do I add client.exists(Policy policy, Key key) and exists(BatchPolicy policy, Key[] keys) to an MRT?​

These policies don't use ReadPolicy.

  • All of the command level policy classes inherit the txn field from the base class. Set the txn property of the appropriate policy class instance and pass it in as a normal Client operation call.

  • Even though ScanPolicy and QueryPolicy also inherit from the base Policy class, the txn field is ignored for those commands.

  • InfoPolicy does not extend the base Policy class and therefore does not have a txn property.

Python client and C client: When creating a transaction object, what are the two optional parameters “reads capacity” and “writes capacity” used for?​

Background: Internally, the transaction object contains 2 hashmaps, and one of the hashmaps is to store the read operations of an MRT and the other hashmap is to store the write operations for it. Each hashmap is implemented internally as a list of linked lists, and the hashmap starts out as a list of one-node linked lists and the number of linked lists is the capacity. When inserting a new read/write single record transaction (SRT), the SRT’s record digest is used as the hashmap key, and a hashing function converts the key to an index to store the operation in the hashmap’s list. There is a chance that a collision occurs if there is another SRT stored in that hashmap, and that SRT’s record digest also occupies that same list index.