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:

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.