DynamoDB und optimistisches Sperren mit Versionsnummer - Amazon-DynamoDB

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.

DynamoDB und optimistisches Sperren mit Versionsnummer

Optimistische Sperren stellen eine Strategie dar, die sicherstellt, dass das clientseitige Element, das Sie aktualisieren (oder löschen), das gleiche Element wie in Amazon DynamoDB ist. Wenn Sie diese Strategie verwenden, werden Ihre Datenbankschreibvorgänge vor dem Überschreiben durch Schreibvorgänge anderer Benutzer geschützt und umgekehrt.

Mit der optimistischen Sperre verfügt jedes Element über ein Attribut, das als Versionsnummer fungiert. Wenn Sie ein Element in einer Tabelle abrufen, zeichnet die Anwendung die Versionsnummer dieses Elements auf. Sie können das Element aktualisieren, jedoch nur, wenn die serverseitige Versionsnummer nicht geändert wurde. Wenn Versionen nicht übereinstimmen, bedeutet das, dass ein anderer Benutzer das Element vor Ihnen geändert hat. Die Aktualisierung schlägt fehlt, da Sie eine veraltete Version des Elements besitzen. Versuchen Sie es in diesem Fall erneut, indem Sie das Element abrufen und dann versuchen, es zu aktualisieren. Die optimistische Sperre hindert Sie daran, versehentlich Änderungen anderer Benutzer zu überschreiben. Sie hindert auch andere Benutzer daran, versehentlich Ihre Änderungen zu überschreiben.

Sie können zwar Ihre eigene optimistische Sperrstrategie implementieren, AWS SDK for Java bietet aber die @DynamoDBVersionAttribute Anmerkung. In der Mappingklasse für Ihre Tabelle legen Sie eine Eigenschaft zum Speichern der Versionsnummer fest und kennzeichnen diese mithilfe dieser Anmerkung. Wenn Sie ein Objekt speichern, wird das entsprechende Element in der DynamoDB-Tabelle über ein Attribut verfügen, das die Versionsnummer speichert. Der DynamoDBMapper weist eine Versionsnummer zu, wenn Sie das Element zum ersten Mal speichern und er erhöht automatisch die Versionsnummer bei jeder Aktualisierung des Elements. Die Aktualisierungs- oder Löschanforderungen sind nur erfolgreich, wenn die clientseitige Objektversion der entsprechenden Versionsnummer des Elements in der DynamoDB-Tabelle entspricht.

ConditionalCheckFailedException wird aufgeworfen, wenn:

  • Sie eine optimistische Sperre mit @DynamoDBVersionAttribute verwenden und sich der Versionswert auf dem Server von dem Wert auf der Client-Seite unterscheidet.

  • Sie Ihre eigenen bedingten Einschränkungen beim Speichern der Daten angeben, indem Sie DynamoDBMapper mit DynamoDBSaveExpression verwenden, und diese Einschränkungen fehlgeschlagen sind.

Anmerkung
  • Globale Tabellen in DynamoDB verwenden bei gleichzeitigen Updates einen Mechanismus, bei dem der letzte Schreibvorgang gültig ist. Bei Verwendung von globalen Tabellen ist immer der letzte Schreibvorgang gültig. In diesem Fall funktioniert das Sperren daher nicht wie erwartet.

  • Transaktionale Schreibvorgänge von DynamoDBMapper unterstützen keine @DynamoDBVersionAttribute-Anmerkung und -Bedingungsausdrücke auf demselben Objekt. Wenn ein Objekt innerhalb eines transaktionalen Schreibvorgangs mit einer Anmerkung versehen ist @DynamoDBVersionAttribute und auch über einen Bedingungsausdruck verfügt, SdkClientException wird ein ausgelöst.

Der folgende Java-Code definiert beispielsweise die Klasse CatalogItem, die über mehrere Eigenschaften verfügt. Die Version-Eigenschaft wird mit der @DynamoDBVersionAttribute-Anmerkung gekennzeichnet.

Beispiel
@DynamoDBTable(tableName="ProductCatalog") public class CatalogItem { private Integer id; private String title; private String ISBN; private Set<String> bookAuthors; private String someProp; private Long version; @DynamoDBHashKey(attributeName="Id") public Integer getId() { return id; } public void setId(Integer Id) { this.id = Id; } @DynamoDBAttribute(attributeName="Title") public String getTitle() { return title; } public void setTitle(String title) { this.title = title; } @DynamoDBAttribute(attributeName="ISBN") public String getISBN() { return ISBN; } public void setISBN(String ISBN) { this.ISBN = ISBN;} @DynamoDBAttribute(attributeName = "Authors") public Set<String> getBookAuthors() { return bookAuthors; } public void setBookAuthors(Set<String> bookAuthors) { this.bookAuthors = bookAuthors; } @DynamoDBIgnore public String getSomeProp() { return someProp;} public void setSomeProp(String someProp) {this.someProp = someProp;} @DynamoDBVersionAttribute public Long getVersion() { return version; } public void setVersion(Long version) { this.version = version;} }

Sie können die @DynamoDBVersionAttribute-Anmerkung auf löschbare Typen anwenden, die durch primitive Wrapper-Klassen bereitgestellt wurden, die wiederum einen löschbaren Typ wie Long und Integer bereitstellen.

Die optimistische Sperre hat folgende Auswirkungen auf diese DynamoDBMapper-Methoden:

  • save – für ein neues Element weist der DynamoDBMapper eine erste Versionsnummer 1 zu. Wenn Sie ein Element abrufen, eine oder mehrere seiner Eigenschaften aktualisieren und versuchen, die Änderungen zu speichern, ist die Speicheroperation nur dann erfolgreich, wenn die clientseitige und die serverseitige Versionsnummer übereinstimmen. Der DynamoDBMapper erhöht die Versionsnummer automatisch.

  • delete – die delete-Methode übernimmt ein Objekt als einen Parameter und der DynamoDBMapper führt einen Versionscheck durch, bevor er das Element löscht. Der Versionscheck kann deaktiviert werden, wenn DynamoDBMapperConfig.SaveBehavior.CLOBBER in der Anforderung angegeben wird.

    Die interne Implementierung der optimistischen Sperre im DynamoDBMapper nutzt die von DynamoDB bereitgestellte Unterstützung für bedingtes Aktualisieren und bedingtes Löschen.

  • transactionWrite

    • Put – für ein neues Element weist der DynamoDBMapper eine erste Versionsnummer 1 zu. Wenn Sie ein Element abrufen, eine oder mehrere seiner Eigenschaften aktualisieren und versuchen, die Änderungen zu speichern, ist die Put-Operation nur dann erfolgreich, wenn die clientseitige und die serverseitige Versionsnummer übereinstimmen. Der DynamoDBMapper erhöht die Versionsnummer automatisch.

    • Update – für ein neues Element weist der DynamoDBMapper eine erste Versionsnummer 1 zu. Wenn Sie ein Element abrufen, eine oder mehrere seiner Eigenschaften aktualisieren und versuchen, die Änderungen zu speichern, ist die Update-Operation nur dann erfolgreich, wenn die clientseitige und die serverseitige Versionsnummer übereinstimmen. Der DynamoDBMapper erhöht die Versionsnummer automatisch.

    • DeleteDynamoDBMapper führt eine Versionsprüfung durch, bevor er das Element löscht. Die Lösch-Operation ist nur dann erfolgreich, wenn die Versionsnummern auf Clientseite und auf Serverseite übereinstimmen.

    • ConditionCheck – die @DynamoDBVersionAttribute-Anmerkung wird für ConditionCheck-Operationen nicht unterstützt. Ein SdkClientException wird ausgelöst, wenn ein ConditionCheck Element mit einer Anmerkung versehen ist. @DynamoDBVersionAttribute

Deaktivieren der optimistischen Sperre

Um die optimistische Sperre zu deaktivieren, können Sie den DynamoDBMapperConfig.SaveBehavior-Aufzählungswert von UPDATE auf CLOBBER ändern. Sie können dies tun, indem Sie eine DynamoDBMapperConfig-Instance erstellen, die eine Versionsüberprüfung überspringt und diese Instance für alle Anforderungen verwendet. Weitere Informationen zu DynamoDBMapperConfig.SaveBehavior und anderen optionalen DynamoDBMapper-Parametern finden Sie unter Optionale Konfigurationseinstellungen für D ynamoDBMapper .

Sie können auch ein Sperrverhalten ausschließlich für eine bestimmte Operation festlegen. Der folgende Java-Ausschnitt verwendet beispielsweise den DynamoDBMapper, um ein Katalogelement zu speichern. Er legt ein DynamoDBMapperConfig.SaveBehavior fest, indem er optionale DynamoDBMapperConfig-Parameter der save-Methode hinzufügt.

Anmerkung

Die transactionWrite Methode unterstützt D ynamoDBMapper Config nicht. SaveBehaviorKonfiguration. Die Deaktivierung von Optimistic Locking für transactionWrite wird nicht unterstützt.

Beispiel
DynamoDBMapper mapper = new DynamoDBMapper(client); // Load a catalog item. CatalogItem item = mapper.load(CatalogItem.class, 101); item.setTitle("This is a new title for the item"); ... // Save the item. mapper.save(item, new DynamoDBMapperConfig( DynamoDBMapperConfig.SaveBehavior.CLOBBER));