Dieser Artikel wurde manuell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen. |
Übersetzung
Original
|
sp_getapplock (Transact-SQL)
Sperrt eine Anwendungsressource.
- [ @Resource= ] 'resource_name'
-
Zeichenfolge, die einen Namen zum Identifizieren der Sperrressource angibt. Die Anwendung muss sicherstellen, dass der Ressourcenname eindeutig ist. Der angegebene Name wird intern als Hashwert in einem Wert gespeichert, der im SQL Server-Sperren-Manager gespeichert werden kann. resource_name ist vom Datentyp nvarchar(255) und hat keinen Standardwert. Wenn eine Ressourcenzeichenfolge länger als nvarchar(255) ist, wird sie auf nvarchar(255) abgeschnitten.
resource_name unterliegt dem Binärvergleich. Daher muss die Groß-/Kleinschreibung unabhängig von den Sortierungseinstellungen der aktuellen Datenbank berücksichtigt werden.
Hinweis
Nachdem eine Anwendungssperre eingerichtet wurde, können nur die ersten 32 Zeichen im Nur-Text-Format abgerufen werden. Die übrigen Zeichen werden hashcodiert.
- [ @LockMode= ] 'lock_mode'
-
Der Sperrmodus, der für eine bestimmte Ressource abgerufen werden soll. lock_mode ist vom Datentyp nvarchar(32) und hat keinen Standardwert. Folgende Werte sind möglich: Shared, Update, IntentShared, IntentExclusive oder Exclusive.
- [ @LockOwner= ] 'lock_owner'
-
Der Besitzer der Sperre. Dabei handelt es sich um den Wert von lock_owner beim Anfordern der Sperre. lock_owner ist vom Datentyp nvarchar(32). Der Wert kann Transaction (Standard) oder Session lauten. Wenn für Transaction der Wert lock_owner angegeben wird, und zwar unabhängig davon, ob dies der Standardwert ist oder ob er explizit angegeben wurde, muss sp_getapplock aus einer Transaktion heraus ausgeführt werden.
- [ @LockTimeout= ] 'value'
-
Der Wert für das Sperrtimeout in Millisekunden. Der Standardwert ist derselbe wie der von @@LOCK_TIMEOUT zurückgegebene Wert. Damit bei Sperranforderungen, die nicht sofort erteilt werden können, nicht auf die Sperre gewartet, sondern ein Fehler zurückgegeben wird, geben Sie 0 an.
- [ @DbPrincipal= ] 'database_principal'
-
Der Benutzer, die Rolle oder die Anwendungsrolle mit Berechtigungen für ein Objekt in einer Datenbank. Zum erfolgreichen Aufrufen einer Funktion muss der Aufrufer der Funktion Mitglied einer der folgenden festen Datenbankrollen sein: database_principal, dbo oder db_owner. Der Standardwert ist public.
>= 0 (Erfolg) oder < 0 (Fehler)
|
Wert |
Ergebnis |
|---|---|
|
0 |
Die Sperre wurde erfolgreich synchron erteilt. |
|
1 |
Die Sperre wurde erfolgreich erteilt, nachdem das Aufheben anderer, inkompatibler Sperren abgewartet wurde. |
|
-1 |
Timeout für die Sperranforderung. |
|
-2 |
Die Sperranforderung wurde abgebrochen. |
|
-3 |
Die Sperranforderung wurde als Deadlockopfer gewählt. |
|
-999 |
Gibt einen Fehler bei Parameterüberprüfung oder einen anderen Aufruffehler an. |
Für eine Ressource bestehende Sperren sind der aktuellen Transaktion oder der aktuellen Sitzung zugeordnet. Der aktuellen Transaktion zugeordnete Sperren werden aufgehoben, wenn für die Transaktion ein Commit oder ein Rollback ausgeführt wird. Der aktuellen Sitzung zugeordnete Sperren werden aufgehoben, wenn die Sitzung abgemeldet wird. Wenn der Server aus irgendeinem Grund heruntergefahren wird, werden alle Sperren aufgehoben.
Die von sp_getapplock erstellte Sperrenressource wird in der aktuellen Datenbank der Sitzung erstellt. Jede Sperrenressource wird durch die kombinierten Werte folgender Elemente identifiziert:
-
Die Datenbank-ID der Datenbank, die die Sperrenressource enthält.
-
Der im @DbPrincipal-Parameter angegebene Datenbankprinzipal.
-
Der im @Resource-Parameter angegebene Name für die Sperre.
Nur ein Mitglied des im @DbPrincipal-Parameter angegebenen Datenbankprinzipals kann Anwendungssperren einrichten, die diesen Prinzipal angeben. Mitglieder der Rollen dbo und db_owner werden implizit als Mitglieder aller Rollen betrachtet.
Mit sp_releaseapplock können Sperren explizit aufgehoben werden. Wenn eine Anwendung mehrere Male sp_getapplock für dieselbe Sperrenressource aufruft, muss sp_releaseapplock genauso oft aufgerufen werden, um die Sperre aufzuheben.
Wenn sp_getapplock mehrere Male für dieselbe Sperrenressource aufgerufen wird, aber eine der Anforderungen einen Sperrmodus angibt, der nicht mit dem vorhandenen Modus übereinstimmt, kommt es in Bezug auf die Ressource zu einer Vereinigung der beiden Sperrmodi. In den meisten Fällen bedeutet dies, dass der Sperrmodus zum Stärkeren der Sperrmodi, d. h. des vorhandenen oder des neu angeforderten, heraufgestuft wird. Der stärkere Sperrmodus wird beibehalten, bis die Sperre endgültig aufgehoben wird, selbst wenn schon vorher Aufrufe zur Aufhebung der Sperre auftreten. In der folgenden Aufrufsequenz bleibt die Ressource im Exclusive-Modus und nicht im Shared-Modus.
USE AdventureWorks2012; GO BEGIN TRANSACTION; DECLARE @result int; EXEC @result = sp_getapplock @Resource = 'Form1', @LockMode = 'Shared'; EXEC @result = sp_getapplock @Resource = 'Form1', @LockMode = 'Exclusive'; EXEC @result = sp_releaseapplock @Resource = 'Form1'; COMMIT TRANSACTION; GO
Ein Deadlock mit einer Anwendungssperre führt keinen Rollback für die Transaktion durch, die die Anwendungssperre angefordert hat. Jeder Rollback, der möglicherweise als Ergebnis des Rückgabewertes benötigt wird, muss manuell ausgeführt werden. Daher wird empfohlen, die Fehlerüberprüfung im Code einzuschließen, sodass bei Rückgabe bestimmter Werte (z. B. -3) ein ROLLBACK TRANSACTION-Vorgang oder eine andere Aktion initiiert wird.
Beispiel:
USE AdventureWorks2012; GO BEGIN TRANSACTION; DECLARE @result int; EXEC @result = sp_getapplock @Resource = 'Form1', @LockMode = 'Exclusive'; IF @result = -3 BEGIN ROLLBACK TRANSACTION; END ELSE BEGIN EXEC @result = sp_releaseapplock @Resource = 'Form1'; COMMIT TRANSACTION; END; GO
SQL Server verwendet die aktuelle Datenbank-ID, um die Ressource zu kennzeichnen. Beim Ausführen von sp_getapplock führt dies zu unterschiedlichen Sperren auf unterschiedlichen Ressourcen, selbst wenn identische Parameterwerte auf verschiedenen Datenbanken verwendet werden.
Verwenden Sie die dynamische Verwaltungssicht sys.dm_tran_locks oder die gespeicherte Systemprozedur sp_lock zum Überprüfen von Sperrinformationen, oder verwenden Sie SQL Server Profiler, um Sperren zu überwachen.
Im folgenden Beispiel wird eine freigegebene Sperre, die der aktuellen Transaktion zugeordnet ist, für die Form1-Ressource in der AdventureWorks2012-Datenbank eingerichtet.
USE AdventureWorks2012;
GO
BEGIN TRAN;
DECLARE @result int;
EXEC @result = sp_getapplock @Resource = 'Form1',
@LockMode = 'Shared';
COMMIT TRAN;
GO
Im folgenden Beispiel wird dbo als Datenbankprinzipal angegeben.
BEGIN TRAN;
EXEC sp_getapplock @DbPrincipal = 'dbo', @Resource = 'AdventureWorks2012',
@LockMode = 'Shared';
COMMIT TRAN;
GO
