In an Oracle NoSQL Database, a transaction is a logical, atomic unit of work which entails one database access operation. In Oracle NoSQL Database every data operation takes place in a single transaction, managed by the system. Users do not have the ability to group multiple operations into a single transaction, although some operations allow multiple rows to participate in a single operation.
Transactional semantics are often described in terms of ACID properties.
- Atomicity means a transaction either completes or fails in entirety. There is no state in between. You don't see a partial completion of a transaction.
- Consistency means the transaction leaves the database in a valid state.
- Isolation means no two transactions mingle or interfere with each other. You get the same result when the two transactions are executed in sequence or executed in parallel.
- Durability means the changes of a transaction are saved and the changes survive any type of failure (network, disk, CPU or a power failure).
Oracle NoSQL Database transactions maintain all these properties. Oracle NoSQL Database offers the user some control over the properties of a transaction. If your transaction involves a number of write operations on rows that share the same shard key, all of the write operations can be executed as a single atomic unit. So all of the operations will execute successfully, or none of them will.
The sequence of the write operations in the transaction is performed in isolation. This means that if you have a thread running a sequence of write operations, then another thread cannot intrude on the data in use by the sequence. The second thread will not be able to see any of the modifications made by the first running sequence until the sequence is complete.
Atomicity and Isolation are not configurable but Oracle NoSQL Database allows users to control Consistency and Durability policies in order to trade off performance for applications that have differing needs for these properties.
Oracle NoSQL Database provides several different consistency policies. At one end of the spectrum, applications can specify absolute consistency, which guarantees that all reads return the most recently written value for a designated key. At the other end of the spectrum, applications capable of tolerating inconsistent data can specify weak consistency, allowing the database to return a value efficiently even if it is not entirely up to date. In between these two extremes, applications can specify time-based consistency to constrain how old a record might be or version-based consistency to support both atomicity for read-modify-write operations and reads that are at least as recent as the specified version.
The following illustration depicts the range of consistency policies that can be used by an application that makes use of Oracle NoSQL Database:
Flexible consistency policies enables developers to easily create business solutions providing data guarantees while meeting application latency and scalability requirements.