Quel niveau d'isolation du serveur sql dois-je choisir pour empêcher les lectures simultanées?

Question

je la transaction suivante:

1. SQL insère un 1 nouvel enregistrement dans une table appelée tbl_document
2. SQL supprime tous les enregistrements correspondant à un critère dans une autre table appelée tbl_attachment
3. SQL insère plusieurs enregistrements dans la tbl_attachment

Tant que cette opération se termine, je ne veux pas que d'autres utilisateurs soient informés des (1) de nouveaux records en tbl_document, (2) les enregistrements supprimés dans tbl_attachment et (3) les enregistrements modifiés dans tbl_attac hment.

Est-ce que Read Is Committed Isolation est le niveau d'isolation correct?

Answer 1

oui, comme ceci:

BEGIN TRANSACTION 

    insert into tbl_document ... 
    delete tbl_attachment where ... 
    inserts into tbl_attachment ... 

COMMIT 

vous pouvez bloquer/utilisateurs de blocage jusqu'à ce que vous avez terminé et engager/annuler la transaction. En outre, quelqu'un pourrait SELECT vos lignes de tbl_attachment après votre insertion dans tbl_document mais avant votre suppression. Si vous avez besoin pour éviter que faire ceci:

BEGIN TRANSACTION 

    select tbl_attachment with (UPDLOCK,HOLDLOCK) where ... 
    insert into tbl_document ... 
    delete tbl_attachment where ... 
    inserts into tbl_attachment ... 

COMMIT 

ou tout simplement supprimer tbl_attachment avant l'insertion dans tbl_document et oublier la sélection avec les indicateurs de verrouillage.

Answer 2

Le niveau d'isolation de transaction de votre écrit n'a pas d'importance. Ce qui est important est le niveau d'isolement de votre lit. Normalement, les lectures vont et non voir votre insertion/mise à jour/suppression jusqu'à ce que soit validée. Le seul niveau d'isolement peut voir les modifications non validées est READ UNCOMMITTED. Si le thread simultané utilise des lectures sales, il n'y a rien que vous pouvez faire dans l'écriture pour l'empêcher. READ UNCOMMITTED peut être soit défini comme niveau d'isolement, soit demandé explicitement avec un indicateur de table (NOLOCK)

Les lectures sales peuvent voir des données de transaction incohérentes (par exemple, le débit n'équilibre pas le crédit d'une opération) et peuvent également entraîner des lectures en double (lire la même ligne plusieurs fois depuis une table) et déclencher des violations de clés mystérieuses.