By default, VoltDB execution queues operate on a FIFO (first in, first out) basis. Which is sufficient for many applications, given the high volume of throughput VoltDB can achieve.
However, there are cases where you may want to prioritize certain business critical transactions over others. The latest VoltDB Java client programming interface (Client2) allows you to specify a priority for individual invocations of procedures to ensure that the transactions that are important to you are given the appropriate attention by the system. This chapter explains:
How prioritization works
How to enable prioritization
How to specify the priority for individual invocations
How to prioritize classes of transactions, such as import, topics, snapshots, and database replication (DR)
Let's look at the voter sample application included with the VoltDB software to help us understand how prioritization works. Normally, the transactions execute on a first in, first out basis (see Figure A below). In the case of the voter application, the critical transactions are the votes being counted by the Vote stored procedure. If you were to prioritize the transactions you are likely to prioritize Vote over Results, which is a convenience procedure that simply provides a summary of the voting thus far and does not need instantaneous response time.
Now, as the application is currently written, the Results procedure does not need prioritizing because it only runs once every five seconds and has little impact on the voting (see Figure B). However, if you make the summary report available on request, it is conceivable that people repeatedly refreshing the report, generating multiple invocations of the Results procedure, could delay processing of the Vote procedure (see Figure C).
The solution is to prioritize the transactions, so that the Vote invocations are processed more frequently than Results invocations. In VoltDB, when you enable prioritized queuing, you can specify a priority from 1 to 8: priority 1 being the most critical and priority 8 being the least.[1]
Two things happen internally when you prioritize a stored procedure call:
First, the client itself prioritizes the requests. If the application is making database calls faster than the server can queue them, the client prioritizes the backlog of requests and sends them to the server(s) based on the priority assigned to each invocation.
Once the requests reach the partition on the server, the individual transactions are sorted into separate queues for each priority value. Then the execution engine processes the transactions based on those priorities, processing transactions from the high priority queues more frequently than from the lower priority queues.
Figure D shows how by assigning different priorities to the Vote and Results procedures (1 and 5, respectively), you can ensure more Vote invocations run and ad hoc Results requests cannot overwhelm the system.
[1] There are actually nine priority levels, from zero (0) to eight. The most critical, priority zero, is reserved for system functions and cannot be specified by the user.
Documentation