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:
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]
18.118.198.83