26 lines
1.8 KiB
HTML
26 lines
1.8 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" xmlns:m="http://www.w3.org/1998/Math/MathML" xmlns:pls="http://www.w3.org/2005/01/pronunciation-lexicon" xmlns:ssml="http://www.w3.org/2001/10/synthesis" xmlns:svg="http://www.w3.org/2000/svg"><head><title>Asynchronous Item Processing</title><link rel="stylesheet" type="text/css" href="docbook-epub.css"/><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"/><link rel="prev" href="apcs04.xhtml" title="Asynchronous Chunk Processing"/><link rel="next" href="apcs06.xhtml" title="Interactions Between Batching and Transaction Propagation"/></head><body><header/><section class="section" title="Asynchronous Item Processing" epub:type="division" id="asyncItemProcessing"><div class="titlepage"><div><div><h2 class="title" style="clear: both">Asynchronous Item Processing</h2></div></div></div><p>The individual items in chunks in the typical
|
|
can also in principle be processed concurrently. In this case the
|
|
transaction boundary has to move to the level of the individual
|
|
item, so that each transaction is on a single thread:
|
|
</p><pre class="programlisting">
|
|
1 | REPEAT(until=exhausted, exception=not critical) {
|
|
|
|
|
2 | REPEAT(size=5, concurrent) {
|
|
|
|
|
3 | TX {
|
|
4 | RETRY(stateful, exception=deadlock loser) {
|
|
4.1 | input;
|
|
5 | } PROCESS {
|
|
| output;
|
|
6 | } RECOVER {
|
|
| recover;
|
|
| }
|
|
| }
|
|
|
|
|
| }
|
|
|
|
|
| }
|
|
</pre><p>This plan sacrifices the optimisation benefit, that the simple plan
|
|
had, of having all the transactional resources chunked together. It
|
|
is only useful if the cost of the processing (5) is much higher than
|
|
the cost of transaction management (3).</p></section><footer/></body></html> |