The opaque transactional topology has overcome the limitation of the transactional topology, and the opaque transactional spout is fault tolerant even if the data source nodes are down. The opaque transactional spout has the following characteristics:
- Every tuple is processed in exactly one batch.
- If a tuple is not processed in one batch, it would be processed in the next batch. But, the second batch doesn't have the same set of tuples as the first processed batch.
In the case of a transactional topology, we would maintain both the txid and count parameters to make the decision whether the tuple was processed earlier or not. On the other hand, in the case of an opaque transactional topology, we would need to store the txid, count, and previous count parameters to maintain the consistency of the database.
For example, we are processing a txid 5 which contains the following set of tuples:
[India] [India] [Japan] [China]
The current state of the key/value in the database is as follows:
India => [count=7, txid=4, previous=5] Japan => [count=10, txid=4, previous=9] China => [count=12, txid=4, previous=10]
The current txid parameter is 5, which is greater than the stored txid. Hence, the fifth batch was not processed earlier. The stored value of count is copied to the previous values of count, the value of count for India is incremented by 2, and the txid parameter is updated from 4 to 5. Similarly, we will increase the count value of Japan and China. After processing the txid value to 5, the state of the database will look like the following tuples:
India => [count=9, txid=5, previous=7] Japan => [count=11, txid=5, previous=10] China => [count=13, txid=5, previous=12]