Documentation > Deployment > Deferred Query Execution

Introduction

The motivation for eventually consistent (or deferred) queries is that some workloads require the DBMS to write to a table that is never, or at least rarely, read from. TPC-C order history logs are a good example. Instead of blocking the partition to execute each of these queries, we can defer these updates to a time when the partition has less useful work to do anyway.

When a query is issued that carries a “deferred” Java annotation, it is placed into a queue for later execution. Deferred queries are executed either during idle downtime or while the partition is blocked waiting for a distributed transaction to complete. When a deferred query is executed, it takes on the transaction ID number of the transaction it was originally issued as part of. Under the assumption that a data item will never be read from, doing this type of work during a distributed transaction does not violate serializability.

Usage

Queries can be set to deferrable with the deferrable configuration parameter. The user must also specify which query should be marked as deferrable.

Example:

ant hstore-benchmark \
  -Dproject=tpcc \
  -Ddeferrable="paymentByCustomerName.insertHistory"

Known Issues

The major problem with the current implementation of deferrable queries is that H-Store makes no guarantee that all deferred queries will ever execute. That is, if there is never a time when the partition is blocked on a distributed transaction or waiting for more work, then queries marked as deferred will never be executed.

To help resolve this issue, a timeout could be added to deferred queries. This would allow the user to set an upper bound on the inconsistency window. The Deferred Java interface/annotation could be modified to accept a timeout parameter. When timeout is reached, H-Store could be modified to put the deferred work into the normal work queue.

Test Cases

For reasons discussed in the previous section, traditional JUnit test cases did not make sense for this project in its current form. For example, if an update is issued, it does not make sense to check to see if that update has been reflected in the database; the whole point of eventual consistency is that the DBMS makes no such strongly consistent guarantees.