Verrouillage de plusieurs enregistrements SQL Server

Question

Mon scénario est le suivant. J'ai une seule entité composée de plusieurs lignes dans plusieurs tables. Conceptuellement, cela peut être vu comme un document unique. Lorsqu'un utilisateur ouvre un "document", toutes les lignes associées doivent être verrouillées, tout comme Windows verrouille un fichier lors de son ouverture. Comme le «document» peut être ouvert jusqu'à ce que l'utilisateur décide de le fermer, je ne pense pas que les transactions soient une solution viable. La seule solution que j'ai trouvée est d'avoir un champ booléen 'Locked' dans chaque table et de le mettre à True sur les lignes pertinentes quand un "document" est ouvert. J'utilise SQL Server 2008 R2.

Des idées?

Answer 1

En supposant que chaque document a un identifiant unique, une solution portable est d'utiliser une seule table qui connaît tous les documents verrouillés:

CREATE TABLE DocumentLocked (
    doc_id INT PRIMARY KEY, 
    session_id <some type>, 
    lock_acquired DATETIME 
); 

Lorsque vous voulez verrouiller un document, essayez d'insérer l'identifiant du document en question avec un identifiant de session identifiant la session propriétaire et l'heure à laquelle vous l'avez verrouillé. En cas d'échec, le document est déjà verrouillé. L'ID de session et les colonnes lock_acquired ne jouent aucun rôle dans le verrouillage. Il permet simplement d'afficher des informations utiles à l'utilisateur, comme, "Ce document a été verrouillé par Rubio à 9h43". Un problème avec cette approche est que les clients plantés peuvent laisser les documents verrouillés pour toujours, vous avez donc besoin d'un mécanisme au niveau de l'application pour verrouiller les verrous. La colonne lock_acquired peut servir de mécanisme de temporisation en demandant à l'application de mettre à jour l'heure de temps en temps, et en l'utilisant pour détecter les verrous périmés.

Si vous ne vous souciez pas de la portabilité, rendez-vous avec la réponse de @ demas.

Answer 2

Vous pouvez utiliser application locking.

Answer 3

Dans votre cas, le "verrouillage" fait probablement partie de vos processus métier et le mécanisme de transaction de bas niveau ne doit pas être utilisé à cette fin. Donc vous avez raison, vous avez besoin d'un champ 'Locked' dans toutes les tables participantes ou un seul dans une table spéciale "lock".