Transaktionen

Services in Schleupen.CS 3.0 unterstützen keine verteilten Transaktionen, da diese unter anderem eine technologische Abhängigkeit mit sich bringen, die unerwünscht ist. Damit wäre bei der Nutzung des MSDTC (Microsoft Distributed Transaction Coordinator) die Verwendung in einem Linux- / Unix-System nicht möglich. Des Weiteren hat ein derartiger Transaction Coordinator, der das 2-Phasen-Commit-Protokoll implementiert das Problem, das bis zum vollständigen Commit nichts geändert werden darf und somit die Locks zum Bottleneck werden, insbesondere wenn viele Services an einer verteiltten Transaktion beteiligt sind (skaliert nicht gut).

Übergreifendes transaktionales oder äquivalentes Verhalten zur Sicherung von Datenkonsistenz wird in Schleupen.CS 3.0 wie folgt umgesetzt:

Sagas: Da in Schleupen.CS jedes Land seine eigene Persistenz besitzt (Database per service (microservices.io)) und zudem häufig nur ein Aggregat pro Transaktion geändert wird, werden Business-Transaktionen notwendig, die sich über mehrere Microservices und Webservices erstrecken. Eine Saga ist dabei eine Folge von einzelnen lokalen Transaktionen. Tritt ein Fehler in einer lokalen Transaktionen auf, werden alle vorherigen einzelnen Transaktionen zurückgerollt. Diese Zurückrollen nennen wir hierbei kompensieren.


Dies ist im Beispiel der Abbildung zu sehen: ein Client startet einen Process Service, der im ersten Schritt einen Service A, dann Service B und zuletzt Service C aufruft. In Service C trete nun ein Fehler in einer lokalen Transaktion auf. Dann werden die in rot dargestellten Aufrufe durchgeführt um die Änderungen wieder zurückzunehmen: Compensate() in Service B und C. Im Template für Process Services besitzt ein Service entsprechend eine Methode namens Compensate().

Da hier auch Timeouts oder andere Fehler auftreten können, müssen diese Operationen zwingend idempotent sein. Services von Schleupen.CS 3.0 unterstützen im Standard Idempotenz, indem im Header ein sogenannter IdempotencyKey transportiert wird. Dieser wird serverseitig ausgewertet. Siehe hierzu auch: Resilienz.

Eventual consistency: In lokalen Transaktionen werden im Allgemeinen ein oder mehrere Aggregate in einem Land geändert. Änderungen an anderen Aggregaten können auch BusinessEvents propagiert werden, so dass die Konsistenz letztendlich wieder hergestellt wird.

Lokale Transaktionen folgen bei Schleupen.CS 3.0 den ACID-Prinzipien. Da Konsistenz und Verfügbarkeit wichtiger als Partition-Tolerance in Schleupen.CS 3.0 sind, wird gemäß des CAP-Theorems, Microsoft Sql Server als Datenbank-Management-System verwendet.

Lokale Transaktionen werden in einem Service im Standard durch Attributierung wie folgt angeschlossen:

[CSOperationBehavior(TransactionScopeRequired = true)]
public async Task<AusleihenResponse> AusleihenAsync(AusleihenRequest request)
{
  ...
}

[OperationBehavior(TransactionScopeRequired = true)]
public AusleihenResponse Ausleihen(AusleihenRequest request)
{
  ...
}

Services in CS 3.0 verwenden den Transaktionsisolations-Level Read-Committed, der automatisch für ein WCF-Behavior gesetzt wird und somit nicht manuell gesetzt werden muss.

Transaktionen werden in der Service-Fassade und nicht in tieferen Schalen die Onion-Modells verwendet!