sanpwc commented on code in PR #2820:
URL: https://github.com/apache/ignite-3/pull/2820#discussion_r1389504176


##########
modules/table/src/main/java/org/apache/ignite/internal/table/distributed/replicator/PartitionReplicaListener.java:
##########
@@ -2383,6 +2424,35 @@ private CompletableFuture<Object> 
applyCmdWithExceptionHandling(Command cmd) {
         });
     }
 
+    private void applyCmdWithRetryOnSafeTimeReorderException(Command cmd, 
CompletableFuture<Object> resultFuture) {
+        raftClient.run(cmd).whenComplete((res, ex) -> {
+            if (ex != null) {
+                if (ex instanceof SafeTimeReorderException || ex.getCause() 
instanceof SafeTimeReorderException) {
+                    assert cmd instanceof SafeTimePropagatingCommand;
+
+                    SafeTimePropagatingCommand safeTimePropagatingCommand = 
(SafeTimePropagatingCommand) cmd;
+
+                    HybridTimestamp safeTimeForRetry = hybridClock.now();
+
+                    if ((cmd instanceof UpdateCommand && !((UpdateCommand) 
cmd).full())

Review Comment:
   > Why is this condition needed? Could you please add a comment explaining 
this?
   
   Added.
   ```
   // Within primary replica it's required to update safe time in order to 
prevent double storage updates in case of !1PC.
   // Otherwise, it may be possible that a newer entry will be overwritten by 
an older one that came as part of the raft
   // replication flow:
   // tx1 = transactions.begin();
   // tx1.put(k1, v1) -> primary.apply(k1,v1) + asynchronous raft replication 
(k1,v1)
   // tx1.put(k1, v2) -> primary.apply(k1,v2) + asynchronous raft replication 
(k1,v1)
   // (k1,v1) replication overrides newer (k1, v2). Eventually (k1,v2) 
replication will restore proper value.
   // However it's possible that tx1.get(k1) will see v1 instead of v2.
   ```
   
   > 
   > Also, this check seems to be fragile. What if we add an analogous request 
in the future, but forget to mention it here?
   > 
   > How about adding a marker interface common for both update commands? It 
might be more difficult to forget about it when adding a third 'update' command 
in the future.
   
   I agree that given solution is fragile. It should be refactored with 
something more reliable in https://issues.apache.org/jira/browse/IGNITE-20124  
TODO added. Here I'm talking not only about safeTime adjustment on retry but 
about general double updates prevention logic.
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to