Salve a tutti..
in questo caso specifico non comprendo comunque bene l'esigenza di un approccio fuori standard con livelli di isolamento diversi...
(non scrivo codice DDL in quanto solitamente le policy del forum mi segano i messaggi, quindi metto DDL molto letterario )
poniamo l'esempio "standard" di dover effettuare operazioni di "aggiornamento" su una tabella, e alla fine degli aggiornamenti fare verifiche di "non aver rotto niente" e da questo eseguire un rollback vs commit.
ovviamente ricordiamo tutti che, all'interno dello stesso spid, quello che @LeoFar indica, cioe' di non poter accedere alle righe coinvolte nei lock imposti dal DML inserito in transazione, "non risulta vero"...
dimostriamolo !
-- pseudo code di DDL tabella:
GeneraNuovaTabella dbo.t (
Id int NOT NULL PRIMARY KEY,
Dati int NOT NULL
);
GO
INSERT INTO dbo.t
VALUES (1, 1), (2, 2), (3, 3);
GO
a questo punto abbiamo la nostra operazione DML di aggiornamento...
SELECT @@TRANCOUNT AS [tranCount];
BEGIN TRAN
SELECT @@TRANCOUNT AS [tranCount];
UPDATE dbo.t
SET Dati = Dati + 100
WHERE Id <> 2;
SELECT * FROM dbo.t; -- <--- questo NON viene bloccato
ROLLBACK
SELECT @@TRANCOUNT AS [tranCount];
SELECT * FROM dbo.t;
--<--------------
tranCount
-----------
0
tranCount
-----------
1
Id Dati
----------- -----------
1 101
2 2
3 103
tranCount
-----------
0
Id Dati
----------- -----------
1 1
2 2
3 3
quindi resto del parere che "tutto questo giro" non risulta necessario, all'interno dell'esecuzione dell'operazione...
Altro caso ovviamente e' il fatto di aprire una transazione in spid
51, lasciarla "appesa", e in spid
100 voler accedere alle righe coinvolte...
quindi, nella finestra di SSMS, blocchiamo l'esecuzione di quanto sopra alla riga
SELECT * FROM dbo.t; -- <--- questo NON viene bloccato
non avendo chiuso la transazione, resta tutto appeso...
Debug.Assert ("fino a qui siamo tutti d'accordo, vero??");
in altra finestra di query, eseguiamo semplicemente
SELECT @@TRANCOUNT AS [tranCount], @@SPID AS [spid];
SELECT * FROM dbo.t;
[code]
il tranCount sara' == 0 in quanto questo comando NON ne imposta di esplicite, ma l'esecuzione restera' appesa in quanto stiamo utilizzando il livello di isolamento "standard", e cio' NON ci fa accedere alle righe/pagine/tabella bloccate...
in questo triviale esempio, con impostazioni standard, SQL Server ha scelto un lock a livello di riga...
[code]
SELECT * FROM dbo.t
WHERE id = 2;
--<-----------
Id Dati
----------- -----------
2 2
ed infatti ho accesso alla riga NON lockata...
quindi, sempre a mio parere, quanto indicato da @LeoFar, ha senso SE vogliamo accedere a dati eventualmente lockati DA uno spid diverso dal "nostro"...
in ogni caso, l'argomento NON e' assolutamente triviale...
per chi desidera approfondire, consiglio la lettura dell'ottimo (e gratuito)
https://www.red-gate.com/library/sql-server-concurrency-locking-blocking-and-row-versioning
di Nostra Signora SQL Server miss Kalen Delaney
salutoni romagnoli domenicali
--
Andrea