Does quarkus support distributed transactions?

[1017727621]

Description
(Describe the feature here.)

Implementation ideas
(If you have any implementation ideas, they can go here, however please note that all design change proposals should be posted to the Quarkus developer mailing list (or the corresponding Google Group; see the decisions process document for more information).

[1017727621]

Below
http://seata.io/en-us/

[1017727621]

Did anyone reply to me?

[mmusgrov]

There are a couple of related issues:

#34181 (Improve / Define distributed transaction support)
#15364 (#15364)

[Raphasha27]

Quarkus does not support distributed transactions (XA) in the traditional JTA sense. The reactive and imperative architectures favor the Saga pattern instead.

Why: Quarkus prioritizes non-blocking, reactive, and cloud-native design. Distributed transactions with 2PC (two-phase commit) block resources and don't scale horizontally.

Alternatives:

1. Saga Pattern (recommended) — choreography or orchestration with compensating actions:

@ApplicationScoped
public class OrderSaga {
    @Inject
    OrderService orderService;
    @Inject
    PaymentService paymentService;
    @Inject
    InventoryService inventoryService;

    @Transactional
    public void placeOrder(Order order) {
        try {
            orderService.create(order);                    // step 1
            paymentService.charge(order.getAmount());       // step 2
            inventoryService.reserve(order.getItems());     // step 3
        } catch (Exception e) {
            // Compensating actions
            if (order.getId() != null) orderService.cancel(order.getId());
            // Payment auto-reverses or call cancel
            // Inventory auto-releases
            throw new RuntimeException("Saga failed", e);
        }
    }
}

2. Outbox Pattern + CDC (Change Data Capture) — for eventual consistency:

@Entity
public class OutboxEvent {
    @Id UUID id;
    String aggregateType;
    String aggregateId;
    String eventType;
    @Lob String payload;
    boolean published;
}

// Write to outbox in the same transaction as your business logic
// Debezium or similar reads the outbox and publishes to Kafka

3. Narayana Transactions (ArjunaJTA) — only for short-lived, low-contention XA scenarios:

# application.properties
quarkus.transaction-manager.enable-recovery=true
quarkus.datasource.jdbc.transactions=xa

But this is not recommended for reactive or high-throughput systems. Use Sagas + messaging for distributed consistency.