VERTRIEB: 1-800-867-1380

Parallelitätsmodell für Azure Managed Cache Service

Letzte Aktualisierung: September 2014

noteHinweis
Hilfestellung bei der Auswahl des für Ihre Anwendung geeigneten Azure Cache-Angebots finden Sie unter Welches Azure-Cacheangebot eigent sich am besten für mich?.

Die Cachearchitektur gestattet jedem Cacheclient den Zugriff auf zwischengespeicherte Daten, wenn diese Clients über die geeigneten Netzwerkzugriffs- und Konfigurationseinstellungen verfügen. Dies stellt für den parallelen Zugriff eine Herausforderung dar.

Zur Unterstützung Ihrer Anwendung beim Umgang mit Problemen mit dem parallelen Zugriff werden optimistische und pessimistischen Parallelitätsmodelle unterstützt.

Im optimistischen Parallelitätsmodell werden für Aktualisierungen zwischengespeicherter Objekte keine Sperren verwendet. Stattdessen erhält und speichert der Cacheclient auch die aktuelle Version eines Objekts, wenn er ein Objekt aus dem Cache abruft. Wenn eine Aktualisierung erforderlich wird, sendet der Cacheclient den neuen Wert für das Objekt zusammen mit der gespeicherten Version des Objekts. Das System aktualisiert das Objekt nur dann, wenn die gesendete Version mit der aktuellen Version des Objekts im Cache übereinstimmt. Mit jeder Aktualisierung eines Objekts wird dessen Versionsnummer geändert. Auf diese Weise wird verhindert, dass mit einer Aktualisierung die Änderungen eines anderen Cacheclients überschrieben werden.

Das Beispiel in diesem Thema zeigt, wie bei der optimistischen Parallelität die Datenkonsistenz sichergestellt wird.

In diesem Beispiel versuchen zwei Cacheclients (cacheClientA und cacheClientB), das gleiche zwischengespeicherte Objekt mit dem gleichen Schlüssel RadioInventory zu aktualisieren.

Zeitpunkt Null: Beide Clients rufen dasselbe Objekt ab

Zum Zeitpunkt Null (T0) instanziieren beide Cacheclients eine Klasse DataCacheItem, um das zwischengespeicherte Objekt zu erfassen, das sie aktualisieren möchten, zusammen mit zusätzlichen Informationen zum zwischengespeicherten Objekt wie etwa Versions- und Taginformationen. Dies wird im folgenden Codebeispiel veranschaulicht.

//cacheClientA pulls the FM radio inventory from cache
string strACSKey = "[Authentication token]";
DataCacheSecurity clientAFactorySecurity = new DataCacheSecurity(strAcsKey);

DataCacheFactoryConfiguration clientAFactoryConfiguration = new DataCacheFactoryConfiguration();
// Set up desired parameters for Cache Factory
clientAFactoryConfiguration.SecurityProperties = clientAFactorySecurityDataCacheFactory;

clientACacheFactory = new DataCacheFactory(clientAFactoryConfiguration);
DataCache cacheClientA = clientACacheFactory.GetCache("catalog");
DataCacheItem radioInventoryA = 
    cacheClientA.GetCacheItem("RadioInventory");

//cacheClientB pulls the same FM radio inventory from cache
// clientBFactorySecurity and clientBFactoryConfiguration omitted for space
DataCacheFactory clientBCacheFactory = new DataCacheFactory();
DataCache cacheClientB = clientBCacheFactory.GetCache("catalog");
DataCacheItem radioInventoryB= 
    cacheClientB.GetCacheItem("RadioInventory");

noteHinweis
Obwohl in diesem Beispiel die Versionsinformationen mit der GetCacheItem-Methode abgerufen werden, um das DataCacheItem-Objekt zu erhalten, ist es auch möglich, die Get-Methode zu verwenden, um das DataCacheItemVersion-Objekt zu erhalten, das dem abgerufenen Cacheelement zugeordnet ist.

Zeitpunkt Eins: Erste Aktualisierung erfolgreich

Zum Zeitpunkt Eins (T1) aktualisiert cacheClientA das zwischengespeicherte Objekt RadioInventory mit einem neuen Wert. Wenn cacheClientA die Put-Methode ausführt, wird die dem RadioInventory-Cache zugeordnete Version erhöht. Zu diesem Zeitpunkt verfügt cacheClientB über ein veraltetes Cacheelement. Dies wird im folgenden Beispiel veranschaulicht.

//at time T1, cacheClientA updates the FM radio inventory
int newRadioInventoryA = 155;

cacheClientA.Put("RadioInventory", newRadioInventoryA, 
    radioInventoryA.Version);

Zeitpunkt Zwei: Fehler bei der zweiten Aktualisierung

Zum Zeitpunkt Zwei (T2) versucht cacheClientB, das zwischengespeicherte RadioInventory-Objekt zu aktualisieren, indem die nun veraltete Versionsnummer verwendet wird. Damit verhindert wird, dass die Änderungen von cacheClientA überschrieben werden, schlägt der Aufruf der Put-Methode durch cacheClientB fehl. Der Cacheclient gibt ein DataCacheException-Objekt aus, bei dem die ErrorCode-Eigenschaft auf CacheItemVersionMismatch festgelegt ist. Dies wird im folgenden Codebeispiel veranschaulicht.

//later, at time T2, cacheClientB tries to 
//update the FM radio inventory, receives DataCacheException with
//an error code equal to DataCacheErrorCode.CacheItemVersionMismatch.
int newRadioInventoryB = 130;

cacheClientB.Put("RadioInventory", newRadioInventoryB,
    radioInventoryB.Version);

Im pessimistischen Parallelitätsmodell sperrt der Client Objekte ausdrücklich, um Vorgänge auszuführen. Andere Vorgänge, die Sperren anfordern, werden zurückgewiesen (das System blockiert Anforderungen nicht), bis die Sperren freigegeben wurden. Wenn Objekte gesperrt sind, wird ein Sperrhandle als ein Ausgabeparameter zurückgegeben. Das Sperrhandle ist zum Aufheben der Sperre des Objekts erforderlich. Falls die Clientanwendung vor der Freigabe eines gesperrten Objekts beendet wird, werden Timeouts bereitgestellt, um die Sperren freizugeben. Gesperrte Objekte laufen niemals ab, sie können jedoch nach dem Aufheben ihrer Sperre sofort ablaufen, wenn ihre Ablaufzeit überschritten wurde.

Weitere Informationen zu den Methoden, die in Verbindung mit dem pessimistischen Parallelitätsmodell verwendet werden, finden Sie unter Parallelitätsmethoden.

noteHinweis
Vorgangsübergreifende Transaktionen werden nicht unterstützt.

noteHinweis
Die Anwendung, die den Cache verwendet, ist für die Ermittlung der Reihenfolge der Sperren und ggf. das Erkennen von Deadlocks verantwortlich.

WarningWarnung
Gesperrte Objekte im Cache können dennoch durch beliebige Cacheclients mit der Methode Put ersetzt werden. Cacheaktivierte Anwendungen sind für die konsistente Verwendung von PutAndUnlock für Elemente verantwortlich, die das pessimistische Parallelitätsmodell verwenden.

Siehe auch

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft