Previous: , Up: API Reference   [Contents][Index]

4.17 Module classy_vote

This module implements a variation of 2-phase commit.

Important to note:

  1. All callbacks involved in the operations are persistently stored. Certain callbacks may be retried after a node restart. Hence, user must make sure that functions involved in the commit are not removed during upgrade.
  2. Vote is rather heavy operation. Do not use it when frequent coordination is needed.
  3. Commit flows may hang for an unlimited time if the coordinator node fails during the decision stage.

4.18 Error Handling

This API uses both synchronous and asynchronous methods of status and error reporting. Both methods must be handled in all cases. Note: when classy_vote:create/1 API returns {ok, _}, it doesn’t mean the commit has been completed.

  1. If this function returns an error tuple, it means the commit followed a "fast abort" path. "Fast abort" path is synchronous, and it implies that no persistent changes have been made to the involved sites (participant and coordinator).
  2. When the function returns {ok, _}, it means commit flow entered "persistent" path. Persistent path continues even after restart of any involved site. Because of that, it uses asynchronous method of status reporting via callbacks passed in the options.

    The coordinator is notified of the outcome via post_vote callback.

    The participants are notified via their respective commit or rollback callbacks.

  3. Additionally, if post_vote, commit or rollback callbacks throw an exception, on_fail callback gets involved.

    Such mechanism is used because classy doesn’t automatically retry any actions that failed on the persistent path: there is a high risk that these actions will just keep failing repeatedly. Instead, they are abandoned until the next node restart. on_fail callback provides a mechanism to signal such failures back to the business logic.

Previous: Module classy_uid, Up: API Reference   [Contents][Index]

JavaScript license information