Priority-based and FIFO-based transaction processing

Discussions

News: Priority-based and FIFO-based transaction processing

  1. Owen Taylor from Gigaspaces posted a solution discussion on priority-based and FIFO-based transaction processing. His initial example is that of a set of stock transactions: while customers' orders aren't dependent on each other, and thus can be unordered, a given customer's orders must be processed in a given order.
    This type of ordering is referred to as FIFO or First In First Out ordering and is a common requirement in transaction-processing applications or almost any stateful application. Another type of Ordering is Priority-based ordering. In this case, transactions need to be processed in a specific order based on a priority tag that has been assigned to them. In this scenario some orders must, 'jump the stack', if they expose a higher priority than the others ahead of them. Parallelization and Ordering (FIFO and/Or Priority) are often seen as contradicting requirements. Indeed, if you look at the way transaction-processing systems are built you will find that in most cases where ordering is required most transactions are routed to a centralized message queue and that queue controls the order in which they are processed. This creates a single-point of contention (or bottleneck) that greatly limits the level of parallelization and scalability that can be achieved by such a system. This is especially true in cases that demand very low-latency or short-lived transactions. Here, where the execution time needs to be a few milliseconds at most, the time it takes to retrieve the transaction from the messaging queue can be greater than the time it takes to actually process the transaction. I consider that a problem.
    Solving priority-based queue issues can be quite difficult. Easy solutions, like creating transient queues, aren't necessarily scalable (thousands of temporary queues being used and discarded) or cleanly manageable. Normally, the JavaSpace model doesn't address this head-on (as matching objects to templates is unordered.) But Gigaspaces has a solution to the issue, through the use of a number of proprietary extensions, including SQL querying (and ordering) of the space. Owen includes an example of how to do a FIFO+Priority Queue in the entry. As an employee of Gigaspaces, he's not quite neutral (nor would one expect him to be), but it's nice to see the space-based technology move forward.
  2. I discovered (a wee bit late) that for some reason the editor I was using converted the character > into &rt; I have now fixed the example code so it uses human readable characters. Cheers, Owen.
  3. if you look at the way transaction-processing systems are built you will find that in most cases where ordering is required most transactions are routed to a centralized message queue and that queue controls the order in which they are processed. This creates a single-point of contention (or bottleneck) that greatly limits the level of parallelization and scalability that can be achieved by such a system.
    Another thing that comes to my mind is SEDA http://www.eecs.harvard.edu/~mdw/proj/seda/ where the events are not queued in a single giant queue, the system is divided into independent stages each of which contains a different queue. Mule uses this architecture.
  4. if you look at the way transaction-processing systems are built you will find that in most cases where ordering is required most transactions are routed to a centralized message queue and that queue controls the order in which they are processed. This creates a single-point of contention (or bottleneck) that greatly limits the level of parallelization and scalability that can be achieved by such a system.


    Another thing that comes to my mind is SEDA http://www.eecs.harvard.edu/~mdw/proj/seda/ where the events are not queued in a single giant queue, the system is divided into independent stages each of which contains a different queue. Mule uses this architecture.
    Actually, SEDA can be very easily implemented with a Space. A Space can be run embedded to the application (within the same JVM) and act as the queue between each component within the SEDA model. One of the nice features of the Space is the fact that Queues are virtualized and actually defined by the template (matching definition) you query the Space with. This means that they can be defined in runtime/deploy time/config time.