code: private void scheduleRepairLogTruncateMsg(long newHandle)
      {
          // skip schedule jobs if no TxnCommitInterests need to be notified
          if (m_sendToHSIds.length == 0 && m_repairLog.hasNoTxnCommitInterests()) {
              return;
          }
  
          SiteTaskerRunnable r = new SiteTaskerRunnable() {
              @Override
              void run()
              {
                  synchronized (m_lock) {
                      if (m_lastSentTruncationHandle < newHandle) {
                          m_lastSentTruncationHandle = newHandle;
                          m_repairLog.notifyTxnCommitInterests(m_lastSentTruncationHandle);
                          if (m_sendToHSIds.length == 0) {
                              return;
                          }
  
                          final RepairLogTruncationMessage truncMsg = new RepairLogTruncationMessage(newHandle);
                          // Also keep the local repair log's truncation point up-to-date
                          // so that it can trigger the callbacks.
                          truncMsg.m_sourceHSId = m_mailbox.getHSId();
                          m_mailbox.deliver(truncMsg);
                          m_mailbox.send(m_sendToHSIds, truncMsg);
                      }
                  }
              }
          };
          if (hostLog.isDebugEnabled()) {
              r.taskInfo = "Repair Log Truncate Message Handle:" + m_repairLogTruncationHandle;
          }
          m_tasks.offer(r);
      }
docs: Schedules a task to be run on the site to send the latest truncation
  handle to the replicas. This should be called whenever the local
  truncation handle advances on the leader to guarantee that the replicas
  will hear about the new handle in case there is no more transactions to
  carry the information over.
  
  The truncation handle is not sent immediately when this method is called
  to avoid sending a message for every committed transaction. In most cases
  when there is sufficient load on the system, there will always be a new
  transaction that this information can piggy-back on. In that case, by the
  time this task runs on the site, the last sent truncation handle has
  already advanced, so there is no need to send the message. This has the
  benefit of sending more truncation messages when the throughput is low,
  which makes the replicas see committed transactions faster.