ciao, benvenuto nel forum :)
Il livello di isolamento che usi è READ COMMITTED, giusto?

giggio240181 ha scritto:

non in cancellazione (anche di righe che non sono interessate alla precedente transazione).

Strano, perché la prima transazione acquisisce un lock sulle sole righe che sta scrivendo, quindi una seconda transazione concorrente alla prima non dovrebbe avere alcun problema a scrivere su ALTRE righe su cui non è stato posto il lock.

In che modo hai verificato questo comportamento? Posta il codice che hai usato.

Ciao!
ok, ora con l'esempio ho capito a cosa ti riferivi parlando delle righe non interessate dall'altra transazione.

Il problema di R5 è che Sql Server non può sapere, a priori, quali siano le righe il cui campo 'c2' vale 'fdsf'. Deve necessariamente fare un table-scan, ovvero esaminare una per una tutte le righe della tabella per scoprire quali di esse corrispondono alla tua ricerca.
Quando arriva ad esaminare la riga con c1=1, su cui la prima transazione ha posto un lock, si mette in attesa del commit prima di procedere con l'eliminazione.

R4 invece non è affetta da questo problema perché come criterio di ricerca lì utilizzi la chiave primaria che è un indice ordinato che identifica chiaramente la posizione di ciascuna riga. E' come quando cerchi una pagina specifica all'interno di un libro: non devi aprirlo e leggere l'intera pagina ma ti basta sfogliare l'angolino in basso a destra finché non la trovi.

Quindi la soluzione potrebbe essere quella di aggiungere un indice anche su c2. In questo modo SQL Server non incapperà più nella riga lockata ed R5 non dovrà più attendere il commit della prima transazione.

Comunque... immagino che la situazione reale sia più complicata di così e, se coinvolge più colonne, aggiungere degli indici potrebbe non essere il consiglio più corretto.

Valuta bene se è effettivamente necessario che la seconda transazione si possa risolvere contemporaneamente alla prima. Oltre che le prestazioni, tieni soprattutto in considerazione il livello di isolamento che hai scelto e i pregi e difetti che porta con sé. Ad esempio il READ COMMITTED non ti protegge da artefatti come Nonrepeatable reads e Phantom reads ma solo tu puoi valutare se questi potranno avere un qualche effetto su ciò che la tua applicazione produce.
http://msdn.microsoft.com/it-it/library/ms378149%28v=sql.90%29.aspx

ciao

---

Modificato da BrightSoul il 17 gennaio 2012 22.33 -