keith-turner commented on a change in pull request #953: fixes #917 Added read
locks
URL: https://github.com/apache/fluo/pull/953#discussion_r147249709
##########
File path:
modules/api/src/main/java/org/apache/fluo/api/client/TransactionBase.java
##########
@@ -60,4 +60,26 @@
* encoded using UTF-8.
*/
void setWeakNotification(CharSequence row, Column col);
+
+ /**
+ * Normally when a Fluo transaction reads data and does not write to it, it
will not collide with
+ * other transactions making concurrent writes. However, all reads done
using this method will
+ * acquire a read lock. These read locks cause collisions with transactions
doing concurrent
+ * writes. However, multiple transactions can get concurrent read locks on
the same row+col
+ * without colliding.
+ *
+ * <p>
+ * Scanning with read locks is not supported. Attempting to call {@code
withReadLock().scanner()}
+ * will throw an {@link UnsupportedOperationException}. This is because
there are an infinite
+ * amount of keys within a range and read locks can not be obtained on them
all.
+ *
+ * <p>
+ * A transaction that only acquires read locks will do nothing at commit
time. In this case no
Review comment:
If updating an external DB it must be done before or after calling commit.
If done before calling commit its possible that a fault occurs or the
transaction collides, however the DB update is already made regardless of
wether the transaction succeeds. If done after commit, then data could change
between commit and DB update. I would want to work out how this feature
could be used to atomically update an external system before changing the
functionality.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
