Library Version 12.1.3.0

Using Predefined Consistency
Prev | Chapter 9. Consistency Guarantees | Next

## Using Predefined Consistency

You can use static instances of the `Consistency` base class to specify certain rigid consistency guarantees. There are two such instances that you can use:

1. `Consistency.ABSOLUTE`

   Requires that the operation be serviced at the master node. In this way, the row(s) will always be consistent with the master.

   This is the strongest possible consistency guarantee that you can require, but it comes at the cost of servicing all read and write requests at the master node. If you direct all your traffic to the master node (which is just one machine for each partition), then you will not be distributing your read operations across your replicas. You also will slow your write operations because your master will be busy servicing read requests. For this reason, you should use this consistency guarantee sparingly.

2. `Consistency.NONE_REQUIRED`

   Allows the store operation to proceed regardless of the state of the replica relative to the master. This is the most relaxed consistency guarantee that you can require. It allows for the maximum possible store performance, but at the high possibility that your application will be operating on stale or out-of-date information.

3. `Consistency.NONE_REQUIRED_NO_MASTER`

   Requires read operations to be serviced on a replica; never the Master. When this policy is used, the read operation will not be performed if the only node available is the Master.

   Where possible, this consistency policy should be avoided in favor of the secondary zones feature.

For example, suppose you are performing a critical read operation that you know must absolutely have the most up-to-date data. Then do this:

    package kvstore.basicExample;

    import oracle.kv.Consistency;
    import oracle.kv.ConsistencyException;
    import oracle.kv.KVStore;
    import oracle.kv.table.PrimaryKey;
    import oracle.kv.table.ReadOptions;
    import oracle.kv.table.Row;
    import oracle.kv.table.Table;
    import oracle.kv.table.TableAPI;

    ...

    // KVStore handle creation is omitted for brevity

    ...

    TableAPI tableH = kvstore.getTableAPI();

    // The name you give to getTable() must be identical
    // to the name that you gave the table when you created
    // the table using the CLI's 'table create' command.
    Table myTable = tableH.getTable("myTable");

    // Construct the PrimaryKey.
    PrimaryKey key = myTable.createPrimaryKey();
    key.put("item", "Bolts");

    // Create the ReadOption with our Consistency policy
    ReadOptions ro = new ReadOptions(Consistency.ABSOLUTE,
                                     0,     // Timeout parameter.
                                            // 0 means use the default.
                                     null); // Timeout units. Null because
                                            // the Timeout is 0.

    // Retrieve the row. This performs a store read operation.
    // Exception handling is skipped for this trivial example.
    try {
        Row row = tableH.get(key, ro);
    } catch (ConsistencyException ce) {
        // The consistency guarantee was not met
    }

Prev | Up | Next
Chapter 9. Consistency Guarantees | Home | Using Time-Based Consistency