DOCSEARCHbyAlgolia
Submit Docs

Apache Seata Documentation

website·Indexed 20 days ago

https://seata.apache.org/

Apache Seata is an open source distributed transaction solution designed for high performance. It provides multiple transaction modes including AT, TCC, Saga, and XA, and includes components such as the Transaction Coordinator (TC), Transaction Manager (TM), and Resource Manager (RM). The documentation covers deployment options via Kubernetes and high availability configurations, as well as contributor guides for the incubating project.

Tokens
1M
Snippets
4.1K
Records
7.2K
Agent score
89%

What's inside Apache Seata

  1. Overview of Seata XA Mode

    v2.5
    Seata XA mode is a distributed transaction mode that manages branch transactions using the XA protocol. It leverages resources (such as databases and message services) that natively support the XA protocol to ensure atomicity. The process consists of two main phases: an Execution Phase (where business SQL is executed and XA prepare is called to ensure persistence) and a Completion Phase (where the Transaction Coordinator drives either a branch commit or a branch rollback).

  2. Overview of Seata XA Mode

    v2.1
    Seata XA mode is a distributed transaction mode that manages branch transactions using the XA protocol. It leverages transaction resources (such as databases and message services) that natively support the XA protocol to ensure atomicity. The process consists of two main phases: an Execution Phase (where business SQL is executed and XA prepare is called to ensure persistence/rollbackability) and a Completion Phase (where the Transaction Coordinator drives the XA branch commit or rollback).

  3. Overview of Seata XA Mode

    v1.4

    Seata XA mode is a distributed transaction mode that manages branch transactions using the XA protocol. It leverages transaction resources (such as databases and message services) that natively support the XA protocol to ensure rollbackability and persistence.

    Prerequisites:

    • Databases that support XA transactions.
    • Java applications accessing the database via JDBC.

  4. Overview of Seata Architecture Roles

    v2.0

    Seata consists of three primary roles:

    • TC (Transaction Coordinator): The server-side component, deployed as a separate standalone server.
    • TM (Transaction Manager): A client-side component integrated into the business system.
    • RM (Resource Manager): A client-side component integrated into the business system.

  5. Overview of Apache Seata Distributed Transaction Solution

    Apache Seata is an open-source distributed transaction framework designed for microservices architectures. It provides a complete solution for managing distributed transactions, supporting multiple programming languages and data storage options. It is compatible with over 10 mainstream RPC frameworks and RDBMS, and integrates with more than 20 other communities.

  6. Overview of Seata TCC Mode

    v2.0
    TCC (Try-Confirm-Cancel) Mode is a distributed transaction solution in Seata that operates at the service layer, making it independent of the underlying database. It is an intrusive solution, meaning developers must manually implement the Try, Confirm, and Cancel operations within the business logic. It is ideal for high-performance core systems and SOA services where granular control over resource locking is required.

  7. Overview of Seata TCC Mode

    TCC (Try-Confirm-Cancel) Mode is a high-performance distributed transaction solution in Seata that operates at the service layer. Unlike AT mode, it is independent of the underlying database, allowing for resource management across different databases and applications. It is an intrusive solution, meaning developers must manually implement the Try, Confirm, and Cancel operations in the business logic. It is best suited for core systems with high performance and scalability requirements.

  8. Overview of Seata XA Mode

    XA mode is a transaction mode within the Seata distributed transaction framework that utilizes the XA protocol to manage branch transactions. Unlike compensatory modes (AT, TCC, Saga), XA mode requires the underlying transaction resources (e.g., databases, message services) to support the XA specification. This allows the resource manager to be aware of the distributed transaction, ensuring global data consistency and isolation (preventing 'dirty reads' of intermediate states) provided the database isolation level is READ_COMMITTED or higher.

  9. Overview of Seata Distributed Transaction Solution

    Seata is an open-source distributed transaction solution designed for high performance and ease of use. It provides a one-stop solution by supporting four different transaction models: AT, TCC, SAGA, and XA.

  10. Overview of Seata AT Mode

    v1.0

    Seata AT mode is a distributed transaction mechanism based on a two-phase commit protocol. It allows for local ACID transactions to be coordinated globally.

    Prerequisites:

    • Relational databases that support local ACID transactions.
    • Java applications accessing the database via JDBC.

    Overall Mechanism:

    • Phase 1: Commits business data and a rollback log within the same local transaction, then releases local locks and connection resources.
    • Phase 2:
      • Commit Case: Asynchronously and quickly cleans up rollback logs.
      • Rollback Case: Performs compensation based on the rollback log created in Phase 1.

  11. Overview of SEATA Saga Pattern

    v1.5

    The Saga pattern is a long transaction solution for distributed systems where each participant executes a local transaction. If any participant fails, the system triggers compensation services for previously successful participants to roll back the transaction.

    Applicable Scenarios:

    • Long and numerous business processes.
    • Integration with third-party companies or legacy systems that cannot support the three interfaces required by the TCC pattern.

    Advantages:

    • High performance: One-phase commits local transactions without locks.
    • High throughput: Event-driven architecture allows asynchronous execution.
    • Simpler implementation of compensation services.

    Disadvantages:

    • Does not guarantee isolation.