Discussion :

[Jim_11]

Bonjour,

Nous utilisons 2 bases de données Sql Server 2008 pour notre application de gestion.

Nous utilisons les transactions pour nous assurer de l'intégrité de la base de données. Etant donné que notre application est multi utilisateurs, notre souci est de garantir l'obtention de données pour les différents utilisateurs.

Souci principal par l'exemple :

Un utilisateur A effectue une sortie de stock (quantité 10).
Le stock avant la modification est de 100.
Utilisateur A valide sa sortie :
- mise en place d'une transaction
- mise à jour de différentes tables par des INSERT (table mouvements de stocks) et UPDATE (table ARTICLE) with UPDLOCK

Problème : si un utilisateur B essaie de lire par un SELECT la fiche en question, => "délai de verrou dépassé"

Une fois que l'utilisateur A valide la transaction, l'enregistrement est à nouveau disponible

Si nous ne bloquons pas l'enregistrement, l'utilsiateur B peut aussi intervenir dessus et bonjour le rendu ...

Voulant garder l'intégrité des données donc les transactions, comment gérer de manière efficace et sans contrainte pour les postes annexes les verrous sur les enregistrements ?

Doit-on passer par d'autres types de verrous ?

Merci de vos réponses.

Jm

[aieeeuuuuu]

- mise à jour de différentes tables par des INSERT (table mouvements de stocks) et UPDATE (table ARTICLE) with UPDLOCK

Sur quelles requêtes utilisez vous l'indicateur UPDLOCK ? pouvez vous détailler un peu cette phase, voire mettre le code ? quel est sa durée d’exécution ?

Par ailleurs, que vous renvoi cette requête

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT @@lock_timeout;

[Jim_11]

Merci pour la réponse rapide.

Donc pour répondre à vos questions :

L'indicateur UPDLOCK est utilisé sur des select qui sont exécutés avant les UPDATE afin de nous assurer que l'enregistrement n'est pas déjà bloqué par un autre processus dans une autre transaction.

Dans tous les cas avec ou sans le select avec UPDLOCK les enregistrements mis à jour dans la transaction ne sont pas accessibles en lecture jusqu'à ce que la transaction soit validée ou annulée.

Par exemple :

1ière session :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
begin tran
select * from Ge_Article with (UPDLOCK) where eIdArticle = 1322
update Ge_Article set eStock = 100 where eIdArticle = 1322

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
begin tran
select * from Ge_Article where eIdArticle = 1322
update Ge_Article set eStock = 100 where eIdArticle = 1322

2ième session :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
set lock_timeout 5000
select * from Ge_Article where eIdArticle = 1322

Le résultat est identique à partir du moment où l'UPDATE est réalisé. L'enregistrement mis à jour est bloqué en lecture et au bout de 5 secondes nous obtenons le message 'Délai d'attente de verrou dépassé'.

Je comprends tout à fait que cela soit normal mais j'aimerai trouver une solution permettant d'éviter cela.

J'avais envisagé l'option consistant à changer le niveau d'isolation des transactions pour le placer à READ UNCOMMITTED mais cela me pose un problème de conscience.

Concernant votre demande relative au Timeout notre application dispose d'une option permettant de modifier ce dernier afin de ne pas avoir de blocage infini en cas d'erreur. Il est par défaut de 5 secondes.

La solution consisterait elle à laisser un timeout infini avec set lock_Timeout -1

Merci

[aieeeuuuuu]

Est-ce qu'il faut en conclure que la partie mise à jour dure plus de 5 secondes ?

C'est beaucoup pour une transaction. Vous n'indiquez pas ce que vous y faites, n'y a-t-il pas moyen d'optimiser cette partie, n'y faites vous pas des choses qui pourraient être sorties de la transaction ?

pour ce qui est du READ UNCOMMITTED , votre problème de conscience risquerait vite de devenir un problème de stock !

[alex34290]

Voilà je viens de prendre le pseudo que je m'étais créer il y a quelques temps déjà.

Alors je vais essayer d'être le plus clair possible dans mes explications.

Le problème que nous rencontrons se produit lorsqu'une application tierce que nous avons développée et qui tourne en service sur un serveur se met en route et traite les fichiers textes envoyés par un application tierce. Ces fichiers textes contiennent les données relatives aux articles à déstocker. L'application en fonction de ces données génère un bon de livraison pour l'établissement et l'unité médicale concernée.

En déroulé voilà ce que cela donne lors de chaque traitement de fichier :

1 - Démarrage d'une transaction (Begin tran)
2 - Recherche de l'établissement (Select classique)
3 - Recherche de l'unité médicale (Select classique)
4 - Lecture de l'établissement pour recherche du dernier n° de bon (Select classique)
5 - Calcul du prochain n° de bon.

Jusqu'à la cela ne pose aucun souci dans l'application de gestion de stock qui peut lire les données sans souci et ce quelles qu'elles soient.

6 - Mise à jour de la fiche de l'établissement pour mise à jour du dernier n° de BL (Update)
7 - Création de l'entête du BL (Insert)
7 - a - Création successive des différentes lignes du BL (Insert)
7 - a - 1 - Validation de la transaction si toutes les lignes ont été créées avec succès (Commit)
7 - a - 2 - Annulation de la transaction si une ligne pose souci (Rollback)
7 - b - Annulation de la transaction en cas d'erreur lors de la création de l'entête (Rollback)

Là où nous rencontrons des difficultés c'est lorsque nous tentons de lire par exemple la fiche de l'établissement lors d'un accès à une fiche Article par exemple et ce lorsque l'application est entre la phase 6 (Mise à jour de la fiche de l'établissement) et l'annulation ou la validation de la transaction.

Les stocks ne sont pas mis à jour donc pas de blocage des fiches Article. En effet le bon généré est mis en attente de validation et ce dernier sera validé par le pharmacien dans l'application de gestion de stock.

Donc pour résumé la transaction inclut :
- Un update
- Au minimum deux insert (un pour l'entête et un par ligne de livraison)

Et ce qui pose souci c'est l'update ...

J'espère avoir été clair dans mes explications. Je pense mais il se peut que je me trompe que le début de la transaction est placé au bon endroit. Elle pourrait cependant être placée après les deux premiers select (Etablissement et unité médicale) mais vu que ces tables contiennent peu d'enregistrements les deux requêtes sont très rapides.

Merci de vos réponses ...

[aieeeuuuuu]

vous n'avez pas répondu : combien de temps dure cette transaction ?