Spezifikation / Framework-APITransactions2.0
Jakarta Transactions
Jakarta Transactions definiert standardisierte Transaktionssteuerung inklusive JTA und XA-Koordination.
Einordnung
Spezifikation / Framework-API
Enterprise-Rolle
In Enterprise-Systemen entscheidet Transaktionsdesign über Datenkonsistenz, Sperren, Performance und Fehlerverhalten.
Fachliches Verständnis
In Enterprise-Systemen entscheidet Transaktionsdesign über Datenkonsistenz, Sperren, Performance und Fehlerverhalten. In der Praxis ist wichtig, die Spezifikation nicht mit der konkreten Runtime zu verwechseln. Der Standard beschreibt die portablen APIs, die Implementierung entscheidet über Konfiguration, Performance, Betrieb und Support.
Kernkonzepte
- @Transactional bzw. UserTransaction je nach Stack.
- Container Managed Transactions.
- XA und Two-Phase Commit.
- Rollback-Regeln und Propagation je Runtime.
Typische Einsatzfälle
- Datenbank und Messaging konsistent koordinieren.
- Application Services als Transaktionsgrenze definieren.
Technisches Beispiel
java
@ApplicationScoped
public class PlaceOrderUseCase {
@Inject OrderRepository orders;
@Inject JMSContext jms;
@Resource(lookup = "java:/jms/queue/order-events") Queue queue;
@Transactional // Unit of Work: Datenänderung und Message in einer Grenze koordinieren.
public OrderId place(PlaceOrderCommand command) {
Order order = Order.place(command);
orders.save(order);
jms.createProducer().send(queue, new OrderPlacedMessage(order.id().value()));
return order.id();
}
}
Architekturregel: Jakarta APIs gehören an Systemgrenzen und Infrastrukturpunkte. Fachentscheidungen bleiben in Application Services und Domain-Modellen testbar und möglichst unabhängig vom Container.
Enterprise-Fallen
- Lange Transaktionen über Remote Calls.
- XA blind einsetzen.
- Fachliche Kompensation ignorieren.
Legacy-Modernisierung
EJB CMT-Transaktionen lassen sich auf Jakarta Transactions oder Runtime-spezifische Transaktionsmechanismen mappen.
Vertiefung: Review-Fragen für Senior-Entwickler
- Welche Spezifikation ist hier wirklich nötig?
- Welche Runtime-Funktion wird genutzt und ist sie portabel?
- Wo liegt die Transaktionsgrenze?
- Sind API-Verträge, DTOs und Domain-Modelle getrennt?
- Ist der Code ohne Application Server testbar?