This is an automated email from the ASF dual-hosted git repository.
hulee pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/helix.wiki.git
The following commit(s) were added to refs/heads/master by this push:
new fe338c3 Updated Concurrency and Parallelism for BucketDataAccessor
(markdown)
fe338c3 is described below
commit fe338c3c57b733c3daca0ac2f8e9faaa38a9b4f7
Author: Hunter Lee <[email protected]>
AuthorDate: Thu Oct 10 14:15:48 2019 -0700
Updated Concurrency and Parallelism for BucketDataAccessor (markdown)
---
Concurrency-and-Parallelism-for-BucketDataAccessor.md | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Concurrency-and-Parallelism-for-BucketDataAccessor.md
b/Concurrency-and-Parallelism-for-BucketDataAccessor.md
index 7b5878f..c968b52 100644
--- a/Concurrency-and-Parallelism-for-BucketDataAccessor.md
+++ b/Concurrency-and-Parallelism-for-BucketDataAccessor.md
@@ -38,10 +38,11 @@ For these two ZNodes, synchronization now becomes a
problem. For this, we'll use
## Optimistic Concurrency Control
Helix's data accessor supports a ZkClient interface called DataUpdater that we
can instrument to implement a ZNode version-based optimistic concurrency
control. It goes like this:
-Read old stats
-Write with the expected version from the stats that was read in Step 1
-If the versions don't match, retry the write
-Monotonically Increasing Version Number
+1. Read old stats
+1. Write with the expected version from the stats that was read in Step 1
+1. If the versions don't match, retry the write
+
+## Monotonically Increasing Version Number
Another property to add to the solution is that it will essentially adopt the
idea of MVCC and have versions increase monotonically. This ensures that there
will never be version conflicts.
To prevent an integer overflow, we will reset the number at a high-enough
version number (Integer.MAX_VALUE for example). Or another easier option is
using long.
