Interblocage et LockTable
Bonjour,
J'ai un problème d'interblocage lorsque j'utilise la commande sql "Lock Table maTable in exclusive mode".
En gros mon code c'est :
Code:
1 2 3 4 5 6 7 8 9
|
Dim ado as new adodb.connection
Ado.ConnectionString = connectionString ' la chaine de connection à une base de données
ado.beginTrans
ado.execute "Lock Table maTable1 in exclusivemode"
' du code s'exécute
ado.commitTrans |
Lorsque deux utilisateurs sont connecté en même temps, le premier obtient le verrou sur la table maTable1, rentre dans le code en section critique. Le deuxième, quant à lui, se trouve bloqué normalement sur le "lock table matable1...".
Mon soucis, c'est que IIS ne redonne jamais la main au premier processus pour qu'il termine la section critique et libère le verrou grâce au commitTrans.
Les deux utilisateurs se bloquent mutuellement !
Je ne suis pas habitué à poster des messages sur un forum, si vous voulez des précisions supplémentaires, n'hésitez pas à les demander.
Merci par avance.
Pas ce type d'interblocage
Bonjour
Merci pour ta réponse, mais mon problème est quelque peu différent. En fait, il ne s'agit pas d'un interblocage "classique" durant lequel un utilisateur u1 bloque les ressources A puis B pendant que u2 bloque B puis A. Dans ce cas classique, u1 peut obtenir A pendant que u2 obtient B, les deux processus s'interblocant au moment de l'obtention de la ressource suivante...
Dans mon cas, les deux utilisateurs ne veulent obtenir un verrou que pour une seule ressource (matable1). Le problème est, je pense, un problème d'ordonnancement.
En effet, lorsque la ligne
Code:
ado.execute "Lock Table maTable1 in exclusivemode"
est exécuté par un utilisateur quelconque, IIS se met en attente de l'obtention de la ressource et aucune autre demande n'est traitée... Si un utilisateur différent avait obtenu cette ressource, IIS ne continue alors pas le traitement du code qui conduit à la libération de la ressource.
J'ai trouvé une première solution avec l'objet "monitor" qui permet de gérer les verrous directement pas asp.net. Dans ce cas, l'ordonnancement est correctement traité par IIS mais cette solution me pose des problèmes de performance et d'évolutivité : les lock table sont en fait dans des composants com, il me faudrait alors poser les verrous avant les appels de chaque fonction qui contient un lock table.