storm git commit: [STORM-2410] modify Trident-state.md

[ka...@apache.org]

Repository: storm
Updated Branches:
  refs/heads/1.0.x-branch 091721dfe -> 4f4c7b4fb


[STORM-2410] modify Trident-state.md


Project: http://git-wip-us.apache.org/repos/asf/storm/repo
Commit: http://git-wip-us.apache.org/repos/asf/storm/commit/4f4c7b4f
Tree: http://git-wip-us.apache.org/repos/asf/storm/tree/4f4c7b4f
Diff: http://git-wip-us.apache.org/repos/asf/storm/diff/4f4c7b4f

Branch: refs/heads/1.0.x-branch
Commit: 4f4c7b4fb8992f879cbbe76cb328c4e13b89b07e
Parents: 091721d
Author: liuzhaokun <li...@zte.com.cn>
Authored: Tue Mar 14 12:11:28 2017 +0800
Committer: Jungtaek Lim <ka...@gmail.com>
Committed: Thu Mar 23 12:49:35 2017 +0900

----------------------------------------------------------------------
 docs/Trident-state.md | 2 --
 1 file changed, 2 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/storm/blob/4f4c7b4f/docs/Trident-state.md
----------------------------------------------------------------------
diff --git a/docs/Trident-state.md b/docs/Trident-state.md
index bb5b1ee..f12b1fd 100644
--- a/docs/Trident-state.md
+++ b/docs/Trident-state.md
@@ -34,8 +34,6 @@ You might be wondering \u2013 why wouldn't you just always use a transactional spou
 
 This is why "opaque transactional" spouts exist \u2013 they are fault-tolerant to losing source nodes while still allowing you to achieve exactly-once processing semantics. We'll cover those spouts in the next section though.
 
-(One side note \u2013 once Kafka supports replication, it will be possible to have transactional spouts that are fault-tolerant to node failure, but that feature does not exist yet.)
-
 Before we get to "opaque transactional" spouts, let's look at how you would design a State implementation that has exactly-once semantics for transactional spouts. This State type is called a "transactional state" and takes advantage of the fact that any given txid is always associated with the exact same set of tuples.
 
 Suppose your topology computes word count and you want to store the word counts in a key/value database. The key will be the word, and the value will contain the count. You've already seen that storing just the count as the value isn't sufficient to know whether you've processed a batch of tuples before. Instead, what you can do is store the transaction id with the count in the database as an atomic value. Then, when updating the count, you can just compare the transaction id in the database with the transaction id for the current batch. If they're the same, you skip the update \u2013 because of the strong ordering, you know for sure that the value in the database incorporates the current batch. If they're different, you increment the count. This logic works because the batch for a txid never changes, and Trident ensures that state updates are ordered among batches.