Parallelitätsmodelle (AppFabric 1.1-Cache)

Die Architektur von Microsoft AppFabric 1.1 für Windows Server gestattet jedem Cacheclient den freien Zugriff auf zwischengespeicherte Daten, wenn diese Clients über die geeigneten Netzwerkzugriffs- und Konfigurationseinstellungen verfügen. Die stellt für die Sicherheit ebenso wie für den parallelen Zugriff eine Herausforderung dar.

Zur Verringerung der Sicherheitsrisiken sollten alle Cacheclients, Cacheserver und primären Datenquellenserver Mitglieder der gleichen Domäne sein und im Umkreisnetzwerk einer Firewall bereitgestellt werden. Darüber hinaus wird dringend empfohlen, die Anwendungskonfigurationsdateien auf den Cacheclients zu sichern.

Zur Unterstützung Ihrer Anwendung beim Umgang mit Problemen mit dem parallelen Zugriff unterstützt AppFabric optimistische und pessimistischen Parallelitätsmodelle. Weitere Informationen zu den Methoden, die für die Abstimmung auf diese Modelle zur Verfügung stehen, finden Sie unter Parallelitätsmethoden.

Optimistisches Parallelitätsmodell

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, wodurch verhindert wird, 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.

Beispiel

In diesem Beispiel versuchen zwei Cacheclients (cacheClientA und cacheClientB) auf zwei unterschiedlichen Anwendungsservern, das gleiche zwischengespeicherte Objekt mit Namen RadioInventory zu aktualisieren.

Zeitpunkt Null: Beide Clients rufen dasselbe Objekt ab

Zum Zeitpunkt Null (T0) instanziieren beide Cacheclients eine DataCacheItem-Klasse, um das zwischengespeicherte Objekt zu erfassen, das sie aktualisieren wollen, zusammen mit zusätzlichen Informationen zum zwischengespeicherten Objekt wie Versions- und Taginformationen. Dies wird mit dem folgenden Diagramm und Codebeispiel illustriert.

'cacheClientA pulls the FM radio inventory from cache
Dim clientACacheFactory As DataCacheFactory = New DataCacheFactory()
Dim cacheClientA As DataCache = _
        clientACacheFactory.GetCache("catalog")
Dim radioInventoryA As DataCacheItem = _
        cacheClientA.GetCacheItem("RadioInventory", "electronics")

'cacheClientB pulls the same FM radio inventory from cache
Dim clientBCacheFactory As DataCacheFactory = New DataCacheFactory()
Dim cacheClientB As DataCache = _
       clientBCacheFactory.GetCache("catalog")
Dim radioInventoryB As DataCacheItem = _
        cacheClientA.GetCacheItem("RadioInventory", "electronics")

//cacheClientA pulls the FM radio inventory from cache
DataCacheFactory clientACacheFactory = new DataCacheFactory();
DataCache cacheClientA = clientACacheFactory.GetCache("catalog");
DataCacheItem radioInventoryA = 
    cacheClientA.GetCacheItem("RadioInventory","electronics");

//cacheClientB pulls the same FM radio inventory from cache
DataCacheFactory clientBCacheFactory = new DataCacheFactory();
DataCache cacheClientB = clientBCacheFactory.GetCache("catalog");
DataCacheItem radioInventoryB= 
    cacheClientA.GetCacheItem("RadioInventory", "electronics");

Hinweis

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 mit dem folgenden Diagramm und Codebeispiel illustriert.

'at time T1, cacheClientA updates the FM radio inventory
Dim newRadioInventoryA As Integer = 155

cacheClientA.Put("RadioInventory", newRadioInventoryA, _
                 radioInventoryA.Version, "electronics")

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

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

Zeitpunkt Zwei: Die zweite Aktualisierung schlägt fehl

Zum Zeitpunkt Zwei (T2) versucht cacheClientB, das zwischengespeicherte RadioInventory-Objekt zu aktualisieren, indem die nun veraltete Versionsnummer verwendet wird. Um zu verhindern, 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 mit dem folgenden Diagramm und Codebeispiel illustriert.

'later, at time T2, cacheClientB tries to 
'update the FM radio inventory, throws DataCacheException with
'an error code equal to DataCacheErrorCode.CacheItemVersionMismatch.
Dim newRadioInventoryB As Integer = 130

cacheClientB.Put("RadioInventory", newRadioInventoryB, _
                 radioInventoryB.Version, "electronics")

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

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

Pessimistisches Parallelitätsmodell

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.

Hinweis

Vorgangsübergreifende Transaktionen werden nicht unterstützt. Die Anwendung, die den Cache verwendet, ist für die Ermittlung der Reihenfolge der Sperren und ggf. das Erkennen von Deadlocks verantwortlich.

Warnung

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

Konzepte

Parallelitätsmethoden
Diagramm der physischen Windows Server AppFabric-Cachearchitektur (AppFabric 1.1-Cache)
Diagramm der logischen Windows Server AppFabric-Cachearchitektur (AppFabric 1.1-Cache)
Entwickeln eines Cacheclients

  2012-03-05