Wenn die Tabellensperren deaktiviert sind, ist die Isolationsstufe, unter der der Upload gespeicherter Prozeduren erfolgt, besonders wichtig, weil damit festgelegt wird, wie nicht festgeschriebene Transaktionen verwaltet werden. Dies ist kein Problem, wenn Tabellensperren aktiviert sind, weil Tabellensperren dafür sorgen, dass keine nicht festgeschriebenen Änderungen in den synchronisierten Tabellen vorhanden sind, wenn der Upload aufgebaut wird.

Ihre gespeicherten Upload-Prozeduren werden auf der Standardisolationsstufe für den Datenbankbenutzer ausgeführt, der in der dbmlsync-Befehlszeile angegeben ist, sofern Sie die Isolationsstufe nicht ausdrücklich in der gespeicherten Upload-Prozedur geändert haben.

Isolationsstufe 0 ist zwar die Standardisolationsstufe für die Datenbank, es wird aber empfohlen, dass Sie Ihre Upload-Prozeduren nicht auf Isolationsstufe 0 ausführen, wenn Sie skriptgesteuerte Uploads ohne Tabellensperren ausführen. Wenn Sie skriptgesteuerte Uploads ohne Tabellensperren implementieren und Isolationsstufe 0 verwenden, können Sie einen Upload von Änderungen vornehmen, die nicht festgeschrieben wurden, woraus sich folgende Probleme ergeben könnten:

Als Alternative können Sie Isolationsstufen 1, 2, 3 oder snapshot verwenden. Bei allen Isolationsstufen wird sichergestellt, dass kein Upload einer nicht festgeschriebenen Transaktion erfolgt.

Wenn Sie Isolationsstufen 1, 2 oder 3 verwenden, kann dies dazu führen, dass Ihre gespeicherten Upload-Prozeduren blockieren, wenn nicht festgeschriebene Änderungen in der Tabelle vorhanden sind. Da Ihre gespeicherten Upload-Prozeduren aufgerufen werden, während dbmlsync mit dem MobiLink-Server verbunden ist, kann dies Serververbindungen binden. Wenn Sie Isolationsstufe 1 verwenden, können Sie das Blockieren verhindern, indem Sie die Tabellen-Hint-Klausel READPAST in Ihren Anweisungen verwenden.

Snapshot-Isolation ist eine gute Alternative, da sie sowohl das Blockieren als auch das Lesen von nicht festgeschriebenen Änderungen verhindert.

Wenn Sie sich dafür entscheiden, Tabellensperren zu deaktivieren, müssen Sie einen Mechanismus verwenden, mit dem Sie Vorgänge verarbeiten können, die beim Eintritt einer Synchronisation nicht festgeschrieben sind. Im nachstehenden Beispiel können Sie erkennen, warum dies ein Problem ist.

Angenommen, eine Tabelle wird mit einem skriptgesteuerten Upload synchronisiert. Der Einfachheit halber wird angenommen, dass nur Einfügungen heraufgeladen werden. Die Tabelle enthält eine insert_time-Spalte, also einen Zeitstempel, der den Zeitpunkt angibt, zu dem eine Zeile eingefügt wurde.

Jeder Upload wird aufgebaut, indem alle festgeschriebenen Zeilen in der Tabelle ausgewählt werden, bei denen der Wert der insert_time-Spalte nach dem Zeitpunkt des letzten erfolgreichen Uploads und vor dem Zeitpunkt liegt, an dem Sie mit dem Aufbauen des aktuellen Uploads begonnen haben (also der Zeitpunkt, zu dem der Hook sp_hook_dbmlsync_set_upload_end_progress aufgerufen wurde). Angenommen, Folgendes tritt ein.

Grundsätzlich kann davon ausgegangen werden, dass ein Vorgang, der vor der Synchronisation eintritt und danach festgeschrieben wird, bei dieser Vorgehensweise verloren geht.

Die einfachste Art der Verarbeitung nicht festgeschriebener Transaktionen besteht darin, den Hook sp_hook_dbmlsync_set_upload_end_progress zu verwenden, um das Verarbeitungsende für jede Synchronisation auf den Startzeitpunkt der ältesten, nicht festgeschriebenen Transaktion auf den Zeitpunkt zu setzen, zu dem der Hook aufgerufen wird. Sie können diesen Zeitpunkt mit der Systemprozedur sa_transactions wie folgt festlegen:

SELECT min( start_time )
FROM sa_transactions()

In diesem Fall müssen Ihre gespeicherten Upload-Prozeduren den Abschluss-Verarbeitungsfortschritt ignorieren, das im Hook sp_hook_dbmlsync_set_upload_end_progress mit sa_transactions kalkuliert und über die #hook_dict-Tabelle übergeben wurde. Die gespeicherten Prozeduren müssen einfach einen Upload aller festgeschriebenen Vorgänge vornehmen, die nach dem Start-Verarbeitsfortschritt eingetreten sind. Damit wird sichergestellt, dass der Download keine Zeilen mit Änderungen überschreibt, für die noch ein Upload durchgeführt werden muss. Außerdem wird damit gewährleistet, dass ein Upload von Vorgängen rechtzeitig erfolgt, auch wenn nicht festgeschriebene Transaktionen vorhanden sind.

Diese Lösung stellt sicher, dass keine Vorgänge verloren gehen. Allerdings kann es vorkommen, dass ein Upload einiger Vorgänge mehr als einmal erfolgt. Ihre serverseitigen Skripten müssen so geschrieben sein, dass sie Vorgänge verarbeiten, deren Upload mehr als einmal vorgenommen wird. Nachstehend sehen Sie ein Beispiel, in dem gezeigt wird, wie bei dieser Vorgehensweise der Upload einer Zeile mehr als einmal erfolgen kann.

Wenn Ihre konsolidierte Datenbank eine SQL Anywhere-Datenbank ist, können Sie redundante Uploads von Einfügevorgängen durch die Anweisung INSERT ... ON EXISTING UPDATE in Ihrem upload_insert-Skript in der konsolidierten Datenbank verarbeiten.

Bei anderen konsolidierten Datenbanken können Sie eine ähnliche Programmlogik in einer gespeicherten Prozedur implementieren, die von Ihrem upload_insert-Skript aufgerufen wird. Schreiben Sie eine Prüfroutine, um zu verifizieren, ob eine Zeile mit dem Primärschlüssel der eingefügten Zeile bereits in der konsolidierten Datenbank existiert. Wenn die Zeile existiert, aktualisieren Sie sie, sonst fügen Sie die neue Zeile ein.

Redundante Uploads von Lösch- und Aktualisierungsvorgängen sind ein Problem, wenn Sie Konflikterkennung oder Konfliktbereinigungslogik auf der Serverseite eingerichtet haben. Wenn Sie Konflikterkennungs- und Konfliktlösungsskripten auf der Serverseite schreiben, müssen diese auch für die Verarbeitung redundanter Uploads ausgelegt sein.

Redundante Uploads von Löschvorgängen können wichtig werden, wenn Primärschlüsselwerte von der konsolidierten Datenbank wiederverwendet werden können. Es gibt die folgende Abfolge von Ereignissen:

• sa_transactions-Systemprozedur
• Isolationsstufe festlegen