Handling Member Failures

These events occur in response to the failure of a single member during a transaction.


  1. If the coordinator fails before a commit is fired, then each of the cohorts aborts the ongoing transaction.

  2. If a participating member fails before commit is fired, then it is simply ignored. If the copies/replicas go to zero for certain keys, then any subsequent update operations on those keys throws an exception as in the case of non-transactional updates. If a commit is fired in this state, then the whole transaction is aborted.

  3. If the coordinator fails before completing the commit process (with or without sending the commit message to all cohorts), the surviving cohorts determine the outcome of the transaction.

    If all of the cohorts are in the PREPARED state and successfully apply changes to the cache without any unique constraint violations, the transaction is committed on all cohorts. Otherwise, if any member reports failure or the last copy the associated rows goes down during the PREPARED state, the transaction is rolled back on all cohorts.

  4. If a participating member fails before acknowledging to the client, then the transaction continues on other members without any interruption. However, if that member contains the last copy of a table or bucket, then the transaction is rolled back.

Note: In this release of SQLFire, a transaction fails if any of the cohorts depart abnormally.