Concorrenza dei cursori (Motore di database)

Microsoft SQL Server supporta quattro opzioni di concorrenza per i cursori del server:

• READ_ONLY

• OPTIMISTIC WITH VALUES

• OPTIMISTIC WITH ROW VERSIONING

• SCROLL LOCKS

• READ_ONLY
  Gli aggiornamenti posizionati eseguiti attraverso il cursore non sono consentiti e sulle righe del set di risultati non viene mantenuto attivo alcun blocco.

• OPTIMISTIC WITH VALUES
  Il controllo della concorrenza ottimistica è una componente standard della teoria del controllo delle transazioni. Il controllo della concorrenza ottimistica viene utilizzato quando la possibilità che un secondo utente o processo aggiorni una riga nell'intervallo che intercorre tra l'apertura del cursore e l'aggiornamento della riga è minima. Quando un cursore viene aperto con questa opzione, i blocchi delle righe sottostanti non vengono mantenuti attivi, con una conseguente ottimizzazione della velocità effettiva. Se l'utente tenta di modificare una riga, i valori correnti della riga vengono confrontati con quelli recuperati durante l'ultima operazione di recupero. Se uno dei valori è stato modificato, nel server viene dedotto che la riga è già stata aggiornata da un altro utente o processo e viene restituito un errore. Se invece i valori sono identici, il server esegue la modifica.

  Quando questa opzione di concorrenza è impostata, l'utente o il programmatore deve gestire la visualizzazione occasionale di un errore che segnala che la riga è stata modificata da un altro utente. In genere, quando un'applicazione riceve un errore di questo tipo, viene aggiornato il cursore, vengono recuperati i nuovi valori e viene quindi consentito all'utente di decidere se apportare o meno la modifica ai nuovi valori. In SQL Server 6.5 e versioni precedenti le colonne di tipo text, ntext e image non vengono utilizzate per i confronti di concorrenza.

• OPTIMISTIC WITH ROW VERSIONING
  Questa opzione per il controllo della concorrenza ottimistica è basata sul controllo delle versioni delle righe. Con il controllo delle versioni delle righe, è necessario che per la tabella sottostante sia disponibile un identificatore di versione utilizzabile dal server per determinare se la riga è stata modificata dopo la lettura nel cursore. In SQL Server tale funzionalità viene implementata tramite il tipo di dati timestamp, ovvero un numero binario che indica la sequenza relativa delle modifiche apportate al database. Ogni database è caratterizzato da un valore timestamp globale specificato in **@@**DBTS. A ogni modifica di una riga che include una colonna di tipo timestamp, SQL Server archivia il valore **@@**DBTS corrente nella colonna di tipo timestamp e quindi incrementa **@@**DBTS. Se la tabella include una colonna di tipo timestamp, i valori timestamp vengono portati a livello di riga. Il server è quindi in grado di confrontare il valore timestamp corrente di una riga con quello archiviato durante l'ultima operazione di recupero per determinare se la riga è stata aggiornata. Nel server non è necessario eseguire il confronto dei valori di tutte le colonne, ma solo dei valori della colonna di tipo timestamp. Se un'applicazione richiede la concorrenza ottimistica con il controllo delle versioni delle righe in una tabella priva di colonne di tipo timestamp, per impostazione predefinita il cursore ripristina il controllo della concorrenza ottimistica basato sui valori.

  Nota

  Per i cursori aperti in origini dati remote, non sono supportati gli aggiornamenti tramite il cursore se nell'origine remota non è inclusa una colonna di tipo timestamp.

• SCROLL LOCKS
  Questa opzione implementa il controllo della concorrenza pessimistica, in base al quale l'applicazione tenta di bloccare le righe di database sottostanti nel momento in cui vengono lette nel set di risultati del cursore. Quando si utilizzano cursori del server, sulla riga viene impostato un blocco di aggiornamento nel momento in cui viene letta nel cursore. Se il cursore è aperto in una transazione, il blocco di aggiornamento della transazione viene mantenuto attivo fino al commit o al rollback della transazione. Il blocco del cursore viene eliminato in corrispondenza del recupero della riga successiva. Se il cursore è stato aperto all'esterno di una transazione, il blocco viene eliminato durante l'operazione di recupero della riga successiva. Per ottenere il controllo completo della concorrenza pessimistica, è pertanto necessario che in una transazione sia aperto un cursore. Un blocco di aggiornamento impedisce l'acquisizione di un blocco di aggiornamento o di un blocco esclusivo tramite altre attività, impedendo in tal modo l'aggiornamento della riga. Un blocco di aggiornamento non ha tuttavia alcun effetto su un blocco condiviso, ovvero non impedisce la lettura delle righe tramite altre attività a meno che queste non richiedano anch'esse la lettura con blocco di aggiornamento.