Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Amazon DynamoDB Transactions: Funktionsweise Mit Amazon DynamoDB Transactions können Sie mehrere Aktionen zusammengruppieren und Sie als eine einzige Alles-oder-nichts-`TransactWriteItems` oder `TransactGetItems`-Produktion übermitteln. Die folgenden Abschnitte beschreiben API-Produktionen, Kapazitätsverwaltung, bewährte Methoden und andere Details zur Verwendung von Transaktionsoperationen in DynamoDB. **Topics** + [TransactWriteItems API](#transaction-apis-txwriteitems) + [TransactGetItems API](#transaction-apis-txgetitems) + [Isolationsstufen für DynamoDB-Transaktionen](#transaction-isolation) + [Handhabung von Transaktionskonflikten in DynamoDB](#transaction-conflict-handling) + [Verwenden von Transaktions-APIs in DynamoDB Accelerator (DAX)](#transaction-apis-dax) + [Kapazitätsverwaltung für Transaktionen](#transaction-capacity-handling) + [Bewährte Methoden für Transaktionen](#transaction-best-practices) + [Verwenden von Transaktions-APIs mit globalen Tabellen](#transaction-integration) + [DynamoDB-Transaktionen im Vergleich mit AWSLabs Transactions Client Library](#transaction-vs-library) ## TransactWriteItems API `TransactWriteItems` ist ein synchroner und idempotenter Schreibvorgang, der bis zu 100 Schreibaktionen in einer einzigen Alles-oder-nichts-Operation zusammengruppiert. Diese Aktionen können auf bis zu 100 verschiedene Elemente in einer oder mehreren DynamoDB-Tabellen innerhalb desselben AWS Kontos und in derselben Region abzielen. Die aggregierte Größe der Elemente in der Transaktion darf 4 MB nicht übersteigen. Die Aktionen werden atomarisch ausgeführt, d. h. entweder sind alle von ihnen oder keine von ihnen erfolgreich. **Anmerkung** Eine `TransactWriteItems`-Operation unterscheidet sich darin von einer `BatchWriteItem`-Operation, dass alle darin enthaltenen Aktionen erfolgreich ausgeführt werden müssen, damit irgendwelche Änderungen vorgenommen werden. Bei einer `BatchWriteItem`-Operation ist es dagegen möglich, dass nur einige der Aktionen im Stapel erfolgreich sind und andere fehlschlagen. Transaktionen können nicht mit Indizes ausgeführt werden. Sie können nicht in derselben Transaktion mit mehreren Operationen auf das gleiche Element abzielen. Beispiel: In derselben Transaktion ist es nicht möglich eine `ConditionCheck`- sowie eine `Update`-Aktion für dasselbe Element auszuführen. Sie können die folgenden Aktionstypen zu einer Transaktion hinzufügen: + `Put` – Initiiert eine `PutItem`-Produktion, um bedingungsabhängig oder bedingungslos ein neues Element zu erstellen oder ein altes Element durch ein neues Element zu ersetzen. + `Update` – Initiiert eine `UpdateItem`-Produktion, um die Attribute eines vorhandenen Elements zu bearbeiten oder ein neues Element zur Tabelle hinzuzufügen, sofern noch nicht vorhanden. Mit dieser Aktion können Sie Attribute für ein vorhandenes Element bedingungsabhängig oder bedingungslos hinzufügen, löschen oder aktualisieren. + `Delete` – Initiiert eine `DeleteItem`-Produktion,, um ein einzelnes Element über seinen Primärschlüssel in einer Tabelle zu löschen. + `ConditionCheck` – Überprüft, ob ein Element vorhanden ist, oder überprüft die Bedingung bestimmter Attribute des Elements. Wenn eine Transaktion in DynamoDB abgeschlossen ist, werden ihre Änderungen an globale sekundäre Indizes (GSIs), Streams und Sicherungen übertragen. Diese Übertragung erfolgt schrittweise: Stream-Datensätze aus derselben Transaktion können zu unterschiedlichen Zeiten erscheinen und sich mit Datensätzen aus anderen Transaktionen überlappen. Stream-Konsumenten sollten nicht davon ausgehen, dass Transaktionen vollständig sind oder dass es sich um Bestellgarantien handelt. Um eine atomare Momentaufnahme der in einer Transaktion geänderten Elemente sicherzustellen, verwenden Sie den TransactGetItems Vorgang, um alle relevanten Elemente zusammen zu lesen. Dieser Vorgang bietet eine konsistente Ansicht der Daten, sodass Sie entweder alle Änderungen einer abgeschlossenen Transaktion oder gar keine sehen. Da die Weitergabe nicht unmittelbar erfolgt, kann eine Tabelle, wenn sie aus Backup ([RestoreTableFromBackup](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_RestoreTableFromBackup.html)) wiederhergestellt oder zu einem Zeitpunkt ([ExportTableToPointInTime](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExportTableToPointInTime.html)) während der Weitergabe exportiert wird, nur einige der Änderungen enthalten, die während einer kürzlich durchgeführten Transaktion vorgenommen wurden. ### Idempotenz Sie können optional ein Client-Token einschließen, wenn Sie einen `TransactWriteItems`-Aufruf machen, um sicherzustellen, dass die Anforderung *idempotent* ist. Durch idempotente Transaktionen lassen sich Anwendungsfehler vermeiden, falls dieselbe Operation aufgrund einer Verbindungszeitüberschreitung oder sonstiger Konnektivitätsprobleme mehrmals übermittelt wird. Wenn der ursprüngliche `TransactWriteItems`-Aufruf erfolgreich war, werden nachfolgende `TransactWriteItems`-Aufrufe mit demselben Client-Token als erfolgreich zurückgegeben, ohne Änderungen vorzunehmen. Wenn der Parameter `ReturnConsumedCapacity` eingestellt ist, gibt der erstmalige `TransactWriteItems`-Aufruf die Anzahl an Schreibkapazitätseinheiten zurück, die beim Vornehmen der Änderungen verbraucht wurden. Nachfolgende `TransactWriteItems`-Aufrufe mit demselben Client-Token geben die Anzahl der Lesekapazitätseinheiten zurück, die beim Lesen des Elements verbraucht wurden. **Wichtige Punkte bezüglich Idempotenz** + Ein Client-Token ist weitere 10 Minuten lang gültig, nachdem die Anforderung, die davon Gebrauch gemacht hat, beendet wurde. Nach 10 Minuten werden alle Anforderungen, die dasselbe Client-Token nutzen, als neue Anforderung angesehen. Deshalb sollten Sie dasselbe Client-Token nach 10 Minuten nicht erneut für dieselbe Anwendung verwenden. + Wenn Sie eine Anforderung mit demselben Client-Token innerhalb des 10-minütigen Idempotenzfenster wiederholen, aber einen anderen Anforderungsparameter ändern, gibt DynamoDB die Ausnahme `IdempotentParameterMismatch` zurück. ### Fehlerbehandlung beim Schreiben Schreibtransaktionen schlagen unter den folgenden Umständen fehl: + Wenn eine Bedingung in einem der Bedingungsausdrücke nicht erfüllt wird. + Wenn ein Transaktionsvalidierungsfehler auftritt, da mehr als eine Aktion in derselben `TransactWriteItems`-Operation auf dasselbe Element abzielt. + Wenn eine `TransactWriteItems`-Anforderung mit einer andauernden `TransactWriteItems`-Operation an mindestens einem Element in der `TransactWriteItems`-Anforderung in Konflikt steht. In diesem Fall schlägt die Anfrage mit der Ausnahme `TransactionCanceledException` fehl. + Wenn für die durchzuführende Transaktion nicht genügend Kapazität bereitgestellt wird. + Wenn ein Element zu groß wird (größer als 400 KB) oder wenn ein lokaler sekundärer Index (LSI) zu groß wird oder wenn aufgrund der durch die Transaktion vorgenommenen Änderungen ein ähnlicher Validierungsfehler auftritt. + Wenn ein Benutzerfehler, wie z. B. ein ungültiges Datenformat, auftritt. Weitere Informationen zum Umgang mit Konflikten mit `TransactWriteItems`-Operationen finden Sie unter [Handhabung von Transaktionskonflikten in DynamoDB](#transaction-conflict-handling). ## TransactGetItems API `TransactGetItems` ist ein synchroner Lesevorgang, der bis zu 100 `Get`-Aktionen zusammengruppiert. Diese Aktionen können auf bis zu 100 verschiedene Elemente in einer oder mehreren DynamoDB-Tabellen innerhalb desselben AWS Kontos und derselben Region abzielen. Die aggregierte Größe der Elemente in der Transaktion darf 4 MB nicht überschreiten. Die `Get`-Aktionen werden atomarisch durchgeführt, d. h. entweder sind alle von ihnen oder keine von ihnen erfolgreich: + `Get` – Initiiert eine `GetItem`-Operation, um einen Satz von Attributen für das Elemente mit dem angegebenen Primärschlüssel abzurufen. Wenn kein passendes Element gefunden wird, gibt `Get` keine Daten zurück. ### Fehlerbehandlung beim Lesen Lesetransaktionen schlagen unter den folgenden Umständen fehl: + Wenn eine `TransactGetItems`-Anforderung mit einer andauernden `TransactWriteItems`-Operation an mindestens einem Element in der `TransactGetItems`-Anforderung in Konflikt steht. In diesem Fall schlägt die Anfrage mit der Ausnahme `TransactionCanceledException` fehl. + Wenn für die durchzuführende Transaktion nicht genügend Kapazität bereitgestellt wird. + Wenn ein Benutzerfehler, wie z. B. ein ungültiges Datenformat, auftritt. Weitere Informationen zum Umgang mit Konflikten mit `TransactGetItems`-Operationen finden Sie unter [Handhabung von Transaktionskonflikten in DynamoDB](#transaction-conflict-handling). ## Isolationsstufen für DynamoDB-Transaktionen Die Isolationsstufen von Transaktionsoperationen (`TransactWriteItems` oder `TransactGetItems`) und anderen Operationen sind folgende: ### SERIALIZABLE Durch die Isolationsstufe *serializable* wird sichergestellt, dass die Ergebnisse mehrerer gleichzeitiger Operationen die gleichen sind, als würde eine Operation erst beginnen, nachdem die vorherige Operation beendet wurde. Die serialisierbare Isolation findet zwischen den folgenden Arten von Operationen statt: + Zwischen Transaktionsoperationen und Standardschreibvorgängen (`PutItem`, `UpdateItem` oder `DeleteItem`). + Zwischen Transaktionsoperationen und Standardlesevorgängen (`GetItem`). + Zwischen einer `TransactWriteItems`-Operation und einer `TransactGetItems`-Operation. Obwohl eine serialisierbare Isolation zwischen Transaktionsoperationen und einzelnen Standardschreibvorgängen in einer `BatchWriteItem`-Operation auftritt, findet keine serialisierbare Isolation zwischen der Transaktion und der `BatchWriteItem`-Operation als Einheit statt. Dementsprechend ist die Isolationsstufe zwischen einer Transaktionsoperation und einzelnen `GetItems` in einer `BatchGetItem`-Operation serialisierbar. Die Isoloationsstufe zwischen der Transaktion und der `BatchGetItem`-Operation als Einheit ist aber *read-committed*. Eine einzelne `GetItem`-Anforderung kann in Bezug auf eine `TransactWriteItems`-Anforderung auf eine von zwei Arten serialisiert werden, entweder vor oder nach der `TransactWriteItems`-Anforderung. Mehrere `GetItem`-Anforderungen, gegen Schlüssel in einem gleichzeitigen `TransactWriteItems`-Anfragen können in beliebiger Reihenfolge ausgeführt werden, und daher sind die Ergebnisse *read-committed*. Wenn beispielsweise `GetItem`-Anforderungen für Element A und Element B gleichzeitig mit einer `TransactWriteItems`-Anforderung ausgeführt werden, die sowohl Element A als auch Element B ändert, gibt es vier Möglichkeiten: + Beide `GetItem`-Anforderungen werden vor der `TransactWriteItems`-Anforderung ausgeführt. + Beide `GetItem`-Anforderungen werden nach der `TransactWriteItems`-Anforderung ausgeführt. + `GetItem`-Anforderung für Element A wird vor der `TransactWriteItems`-Anforderung ausgeführt. Für Element B wird die `GetItem` nach `TransactWriteItems` ausgeführt. + `GetItem`-Anforderung für Element B wird vor der `TransactWriteItems`-Anforderung ausgeführt. Für Element A wird die `GetItem` nach `TransactWriteItems` ausgeführt. Wenn die serialisierbare Isolationsstufe für mehrere `GetItem`-Anfragen bevorzugt wird, verwenden Sie `TransactGetItems`. Wenn mehrere Elemente, die während der Übertragung Teil derselben Transaktionsschreibanfrage waren, nicht transaktionell gelesen werden, ist es möglich, dass Sie den neuen Status einiger Elemente und den alten Status der anderen Elemente lesen können. Sie können den neuen Status aller Elemente, die Teil der Transaktionsschreibanfrage waren, nur lesen, wenn eine erfolgreiche Antwort für den transaktionalen Schreibvorgang eingegangen ist, was darauf hinweist, dass die Transaktion abgeschlossen wurde. Sobald die Transaktion erfolgreich abgeschlossen wurde und eine Antwort eingegangen ist, können nachfolgende, *letztendlich konsistente* Lesevorgänge aufgrund des Konsistenzmodells von DynamoDB für kurze Zeit immer noch den alten Status zurückgeben. Damit die aktuellsten Daten unmittelbar nach einer Transaktion gelesen werden können, sollten Sie [*strikt konsistente*](HowItWorks.ReadConsistency.md#HowItWorks.ReadConsistency.Strongly) Lesevorgänge verwenden, indem Sie den Wert `ConsistentRead` auf „true“ setzen. ### READ-COMMITTED *Read-committed*Isolation stellt sicher, dass Lesevorgänge immer festgeschriebene Werte für ein Element zurückgeben. Beim Lesen wird niemals eine Ansicht des Elements angezeigt, das einen Status aus einem transaktionalen Schreibvorgang darstellt, der letztendlich nicht erfolgreich war. Read-committed Isolation verhindert nicht, dass Änderungen des Elements unmittelbar nach dem Lesevorgang vorgenommen werden. Die Isolationsstufe ist read-committed zwischen allen Transaktionsoperationen und allen Lesevorgängen, die mehrere Standard-Lesevorgänge (`BatchGetItem`, `Query` oder `Scan`) umfassen. Wenn bei einem transaktionalen Schreibvorgang ein Element mitten in einer `BatchGetItem`-, `Query`- oder `Scan`-Operation aktualisiert wird, gibt der nachfolgende Teil des Lesevorgangs den neu festgeschriebenen Wert zurück (mit `ConsistentRead)` oder möglicherweise einem zuvor festgeschriebenem Wert (letztendlich konsistente Lesevorgänge). ### Zusammenfassung des Vorgangs Die folgende Tabelle gibt einen Überblick über die Isolationsstufen zwischen einer Transaktionsoperation (`TransactWriteItems` oder `TransactGetItems`) und anderen Operationen. | Operation | Isolationsstufe | | --- | --- | | `DeleteItem` | *Serializable* | | `PutItem` | *Serializable* | | `UpdateItem` | *Serializable* | | `GetItem` | *Serializable* | | `BatchGetItem` | *Read-committed*\* | | `BatchWriteItem` | *NICHT Serializable*\* | | `Query` | *Read-committed* | | `Scan` | *Read-committed* | | Andere Transaktionsoperationen | *Serializable* | Mit einem Sternchen (\*) markierte Stufen gelten für die Operation als Einheit. Einzelne Aktionen innerhalb dieser Operationen besitzen jedoch die Isolationsstufe *serializable*. ## Handhabung von Transaktionskonflikten in DynamoDB Bei Anforderungen auf Elementebene kann für ein Element in einer Transaktion ein Transaktionskonflikt auftreten. Transaktionskonflikte können in den folgenden Szenarien auftreten: + Eine `PutItem`-, `UpdateItem`- oder `DeleteItem`-Anforderung für ein Element konfligiert mit einer laufenden `TransactWriteItems`-Anforderung, die dasselbe Element enthält. + Ein Element in einer `TransactWriteItems`-Anforderung ist Teil einer anderen laufenden `TransactWriteItems`-Anforderung. + Ein Element in einer `TransactGetItems`-Anforderung ist Teil einer laufenden `TransactWriteItems`-, `BatchWriteItem`-, `PutItem`-, `UpdateItem`- oder `DeleteItem`-Anforderung. **Anmerkung** Wenn eine `PutItem`-, `UpdateItem`- oder `DeleteItem`-Anforderung abgelehnt wird, schlägt die Anforderung mit einer `TransactionConflictException` fehl. Wenn irgendeine Anforderung auf Elementebene in `TransactWriteItems` oder `TransactGetItems` abgelehnt wird, schlägt die Anforderung mit einer `TransactionCanceledException` fehl. Wenn diese Anfrage fehlschlägt, AWS wiederholen SDKs die Anfrage nicht. Die Ausnahme enthält die Liste von [CancellationReasons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CancellationReason.html), sortiert nach der Liste der Elemente im `TransactItems` Anforderungsparameter. Die Fehlermeldung der Ausnahme enthält auch eine Zeichenkettendarstellung der Codes für die Stornierungsgründe. Wenn eine laufende `TransactWriteItems`- oder `TransactGetItems`-Operation mit einer gleichzeitigen `GetItem`-Anforderung im Konflikt steht, können beide Operationen erfolgreich durchgeführt werden. Die [TransactionConflict CloudWatch Metrik](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html) wird für jede fehlgeschlagene Anfrage auf Artikelebene inkrementiert. ## Verwenden von Transaktions-APIs in DynamoDB Accelerator (DAX) `TransactWriteItems` und `TransactGetItems` werden in DynamoDB Accelerator (DAX) mit den gleichen Isolierungsstufen wie in DynamoDB unterstützt. `TransactWriteItems` schreibt über DAX. DAX übergibt eineN `TransactWriteItems`-Aufruf an DynamoDB und gibt die Antwort zurück. Um den Cache nach dem Schreiben aufzufüllen, ruft DAX `TransactGetItems` im Hintergrund für jedes Element im `TransactWriteItems`-Vorgang auf, wodurch zusätzliche Lesekapazitätseinheiten verbraucht werden. (Weitere Informationen finden Sie unter [Kapazitätsverwaltung für Transaktionen](#transaction-capacity-handling).) Diese Funktion ermöglicht es, dass Ihre Anwendungslogik einfach bleibt. Außerdem können Sie so DAX für Transaktionsoperationen sowie für nicht transaktionale Operationen verwenden. `TransactGetItems`-Aufrufe werden über DAX übergeben, ohne dass Elemente lokal zwischengespeichert werden. Dies ist das gleiche Verhalten wie bei Strongly-Consistent-Lese-APIs in DAX. ## Kapazitätsverwaltung für Transaktionen Es fallen keine zusätzlichen Kosten für das Aktivieren von Transaktionen für Ihre DynamoDB-Tabellen an. Sie zahlen nur für Lese- oder Schreibvorgänge, die Teil Ihrer Transaktion sind. DynamoDB führt zwei zugrunde liegende Lese- oder Schreibvorgänge für jedes Element in der Transaktion aus: einen zum Vorbereiten der Transaktion und einen zum Festschreiben der Transaktion. Die beiden zugrunde liegenden read/write Operationen sind in Ihren CloudWatch Amazon-Metriken sichtbar. Diese Kapazität wird auch dann verbraucht, wenn eine Transaktion nicht erfolgreich ist. Ein `TransactWriteItems` `TransactGetItems` Oder-Aufruf, der abgebrochen wird — z. B. weil eine Bedingung in einem `ConditionCheck` oder einem anderen Vorgang als falsch ausgewertet wird (ein `ConditionalCheckFailed` Abbruchgrund) — verbraucht immer noch die zugrunde liegende Lese- oder Schreibkapazität für die Elemente, die versucht wurden, genauso wie es bei einer erfolgreichen Transaktion der Fall ist. Wenn Sie Kapazität für Ihre Tabellen bereitstellen, planen Sie zusätzliche Lese- und Schreibvorgänge ein, die für transaktionale APIs erforderlich sind. Angenommen, Ihre Anwendung führt eine Transaktion pro Sekunde aus und jede Transaktion schreibt drei 500-Byte-Elemente in Ihre Tabelle. Jedes Element erfordert zwei Schreibkapazitätseinheiten (Write Capacity Units, WCUs): eine zur Vorbereitung der Transaktion und eine zum Speichern der Transaktion mit Commit. In diesem Fall müssten Sie daher sechs WCUs für die Tabelle bereitstellen. Wenn Sie im vorherigen Beispiel DynamoDB Accelerator (DAX) verwendet haben, nutzen Sie für jedes Element im `TransactWriteItems`-Aufruf auch zwei Lesekapazitätseinheiten (RCUs). In diesem Fall müssen Sie sechs zusätzliche WCUs für die Tabelle bereitstellen. Wenn Ihre Anwendung eine Lesetransaktion pro Sekunde ausführt und jede Transaktion drei 500-Byte-Elemente in Ihrer Tabelle liest, müssen Sie der Tabelle sechs Lesekapazitätseinheiten (Read Capacity Units, RCUs) bereitstellen. Zum Lesen jedes Elements werden zwei RCUs benötigt: eine zur Vorbereitung der Transaktion und eine zum Ausführen der Transaktion. Außerdem ist das SDK-Standardverhalten, Transaktionen im Falle der Ausnahme `TransactionInProgressException` wiederholt zu versuchen. Planen Sie zusätzliche Lesekapazitätseinheiten (RCUs) ein, die von diesen Wiederholversuchen verbraucht werden. Dies gilt auch, wenn Sie Transaktionen in Ihrem eigenen Code mit einem `ClientRequestToken` wiederholt versuchen. ## Bewährte Methoden für Transaktionen Erwägen Sie bei der Verwendung von DynamoDB-Transaktionen die folgenden empfohlenen Methoden. + Aktivieren Sie für Ihre Tabellen das Auto Scaling oder stellen Sie sicher, dass Sie die von Ihnen bereitgestellte Durchsatzkapazität zum Ausführen der beiden Lese- oder Schreibvorgänge für jedes Element in der Transaktion ausreicht. + Wenn Sie kein AWS bereitgestelltes SDK verwenden, fügen Sie bei einem `TransactWriteItems` Aufruf ein `ClientRequestToken` Attribut hinzu, um sicherzustellen, dass die Anfrage idempotent ist. + Gruppieren Sie Operationen nur dann als eine Transaktion zusammen, wenn dies wirklich erforderlich ist. Beispiel: Wenn eine einzelne Transaktion mit 10 Operationen in mehrere Transaktionen aufgeteilt werden kann, ohne die korrekte Funktionsweise der Anwendung zu gefährden, wird zur Aufteilung der Transaktion geraten. Weniger komplexe Transaktionen verbessern den Durchsatz und sind mit größerer Wahrscheinlichkeit erfolgreich. + Wenn mehrere Transaktionen dieselben Elemente gleichzeitig aktualisieren, können Konflikte entstehen, die zum Abbruch der Transaktionen führen. Wir empfehlen die folgenden bewährten DynamoDB-Methoden für die Datenmodellierung, um solche Konflikte zu minimieren. + Wenn ein Satz von Attributen häufig im Rahmen einer einzelnen Transaktion über mehrere Elemente hinweg aktualisiert wird, empfiehlt es sich, die Attribute in einem einzigen Element zusammenzugruppieren, um den Umfang der Transaktion zu reduzieren. + Vermeiden Sie es, Transaktionen zur massenweisen Aufnahme von Daten zu verwenden. `BatchWriteItem` eignet sich besser für Massenschreibvorgänge. ## Verwenden von Transaktions-APIs mit globalen Tabellen Transaktionsoperationen bieten Garantien für Atomizität, Konsistenz, Isolierung und Haltbarkeit (ACID) nur innerhalb der AWS Region, in der die Schreib-API aufgerufen wurde. Regionsübergreifende Transaktionen werden in globalen Tabellen nicht unterstützt. Angenommen, Sie haben eine globale Tabelle mit Replikaten in den Regionen USA Ost (Ohio) und USA West (Oregon) und Sie führen einen `TransactWriteItems`-Vorgang in der Region USA Ost (Nord-Virginia) aus. Dann sind möglicherweise teilweise abgeschlossene Transaktionen in der Region USA West (Oregon) zu beobachten, während Änderungen repliziert werden. Die Änderungen werden erst dann in die anderen Regionen repliziert, nachdem sie in der Quellregion in die Datenbank eingetragen wurden. ## DynamoDB-Transaktionen im Vergleich mit AWSLabs Transactions Client Library DynamoDB-Transaktionen bietet einen kostengünstigeren, zuverlässigeren und leistungsfähigeren Ersatz für die [AWSLabs](https://github.com/awslabs) Transactions Client Library. Wir empfehlen, Ihre Anwendungen für die Nutzung der nativen, serverseitigen Transaktions-APIs zu aktualisieren.