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-Transaktionen können Sie mehrere Aktionen gruppieren und sie als einzelne all-or-nothing `TransactWriteItems` oder `TransactGetItems` Operation einreichen. 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 Transactional 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 Sie transaktionale Tabellen APIs mit globalen Tabellen](#transaction-integration) + [DynamoDB-Transaktionen im Vergleich zur AWSLabs Transactions-Clientbibliothek](#transaction-vs-library) ## TransactWriteItems API `TransactWriteItems`ist eine synchrone und idempotente Schreiboperation, die bis zu 100 Schreibaktionen in einer einzigen Operation gruppiert. all-or-nothing 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ärindizes (GSIs), Streams und Backups weitergegeben. 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. Um sicherzustellen, dass unmittelbar nach einer Transaktion möglichst up-to-date viele Daten gelesen werden, sollten Sie Strongly [*Consistent Reads verwenden*](HowItWorks.ReadConsistency.md#HowItWorks.ReadConsistency.Strongly), indem Sie den Wert `ConsistentRead` auf true setzen. ### READ-COMMITTED Durch die Isolation *Read-committed* wird sichergestellt, dass Lesevorgänge immer festgeschriebene Werte für ein Element zurückgeben – der Lesevorgang wird niemals eine Sicht auf das Element präsentieren, die einen Zustand aus einem letztlich nicht erfolgreichen transaktionalen Schreibvorgang darstellt. Die Isolation "Read-committed" verhindert keine Änderungen am Element direkt nach dem Lesevorgang. 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*\$1 | | `BatchWriteItem` | *NICHT Serializable*\$1 | | `Query` | *Read-committed* | | `Scan` | *Read-committed* | | Andere Transaktionsoperationen | *Serializable* | Mit einem Sternchen (\$1) 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 SDKs wiederholen Sie die Anfrage nicht. Wenn Sie den verwenden AWS SDK für Java, enthält die Ausnahme die Liste der [CancellationReasons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CancellationReason.html), sortiert nach der Liste der Elemente im `TransactItems` Anforderungsparameter. Bei anderen Sprachen ist in der Fehlermeldung der Ausnahme eine Zeichenfolgendarstellung der Liste enthalten. 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 Elementebene inkrementiert. ## Verwenden von Transactional 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 dasselbe Verhalten wie beim stark konsistenten Lesen in DAX. APIs ## 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. Planen Sie die zusätzlichen Lese- und Schreibvorgänge ein, die für Transaktionen erforderlich sind APIs , wenn Sie Kapazität für Ihre Tabellen bereitstellen. Angenommen, Ihre Anwendung führt eine Transaktion pro Sekunde aus und jede Transaktion schreibt drei 500-Byte-Elemente in Ihre Tabelle. Für jedes Element sind zwei Schreibkapazitätseinheiten (WCUs) erforderlich: eine für die Vorbereitung der Transaktion und eine für den Commit der Transaktion. Daher müssten Sie sechs für WCUs die Tabelle bereitstellen. Wenn Sie im vorherigen Beispiel DynamoDB Accelerator (DAX) verwenden würden, würden Sie auch zwei Lesekapazitätseinheiten (RCUs) für jedes Element im `TransactWriteItems` Aufruf verwenden. Sie müssten also sechs weitere RCUs 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üssten Sie der Tabelle entsprechend sechs Lesekapazitätseinheiten (RCUs) bereitstellen. Zum Lesen jedes Elements sind zwei erforderlich RCUs: eine für die Vorbereitung der Transaktion und eine für die Ausführung der Transaktion. Außerdem ist das SDK-Standardverhalten, Transaktionen im Falle der Ausnahme `TransactionInProgressException` wiederholt zu versuchen. Planen Sie die zusätzlichen Lesekapazitätseinheiten (RCUs) ein, die diese Wiederholungen verbrauchen. 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 Sie transaktionale Tabellen APIs mit globalen Tabellen Transaktionsoperationen bieten Garantien für Atomizität, Konsistenz, Isolation 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 zur AWSLabs Transactions-Clientbibliothek DynamoDB-Transaktionen bieten einen kostengünstigeren, robusteren und leistungsfähigeren Ersatz für die [AWSLabs](https://github.com/awslabs)Transactions-Clientbibliothek. Wir empfehlen Ihnen, Ihre Anwendungen so zu aktualisieren, dass sie die native, serverseitige Transaktion verwenden. APIs