Discussion :

[jbrasselet]

Bonjour,

je ne sais pas trop où chercher et j'avoues que j'aborde un sujet que je ne maitrise pas particulièrement (voir pas beaucoup)

Dans le cadre de mon application, des utilisateurs vont créer des dossiers ayant des Id différents (composé d'un numéro d'année et d'un identifiant contenu dans une table NumeroDossier)

Seulement lorsque je vais chercher cet identifiant et l'incrémenter il ne faut pas qu'un autre thread aille lire la table en question.

Pour être plus explicite:
Ma table NumeroDossier contient 12.

Un utilisateur va créer un nouveau dossier. Mon processus va donc lire la table numéro dossier et l'incrémenter à 13.

Ainsi mes numéro de dossier sont toujours unique.
Seulement si deux utilisateurs crééent des dossiers en même temps et que les deux lectures de la table NumeroDossier se font en même temps je me retrouve avec un problème d'intégrité de clé.

On m'a orienté sur la piste du monothread (possible en java)
Je voulais savoir si cela était possible en .Net et si vous aviez des articles à me conseiller sur ce sujet.

Cordialement

[jbrasselet]

Je sais pas comment j'avais fait pour le louper (plus les yeux en face des trous moi) mais hop:
http://emerica.developpez.com/csharp/threads/#LC

Le lock(this) semble convenir.
Y-a-t-il des subtilités auxquelles je dois faire attention?

[luggerhouse]

Personnellement je ne suis pas tout a fait convaincu...

L'instruction lock(this) semble plutôt s'assurer que les lignes de codes qui suivent soient bien exécutées par l'application peu importe les autres tâche que doit assurer la machine local. Par contre, il n'est pas spécifié quelle sera la priorité au niveau des utilisateurs multiples.

Personnellement je regarderais plutôt du côté de ta base de donnée pour "locker" le champs que tu lis pendant la lecture. Ainis, si 2 utilisateurs arrivent en même temps, le second devra faire une pause jusqu'à ce que la lecture du premier soit terminée.

Bonne chance!

LuggerHouse

[jbrasselet]

Oui mais il est tout de même dit

Lorsqu'une tâche voudra débiter le compte, elle appellera la méthode DebiterCompte en lui passant un montant, et si aucune autre tâche n'est actuellement en train d'exécuter la partie protégée, elle pourra entrer dans la zone de code critique. Sinon, la tâche sera placée dans une file d'attente.

Ca veut bien dire qu'un seul thread peut accéder à cette partiue du code à un moment donné?

[guitoux1]

ben moi j'utiliserais les deux !! les transactions SQL et les lock de thread

[luggerhouse]

Oui mais il est tout de même dit


Ca veut bien dire qu'un seul thread peut accéder à cette partiue du code à un moment donné?

Effectivement, mais sur chaque stations puisque l'application est local et non centrale (server side). Ainsi il est toujours possible que 2 stations arrivent à la fonction en même temps et que tu ai un problème de clé corrompue...

[jbrasselet]

Donc le lock, si j'ai bien compris, ne fonctionne pas si j'ai deux utilisateurs qui accèdent en même temps à cette partie de mon code?
Ca sert à rien alors

J'ai jeté un oeil sur un lock coté SQL mais je n'ai pas vu d'option me permettant de faire un lock d'une table en lecture? (personne ne peut lire la table si elle est déjà prise)

[Sphax]

Salut,

Le lock n'empeche pas deux utilisateurs d'acceder en même temps au même code mais deux threads (d'un même process bien sûr) ce qui n'est pas pareil.

Donc, si ton appli est une appli client lourd (winform) chaque utilisateur a sa propre appli, un processus par client, le lock ne te sert pas à grand chose et il faut passer par un autre mécanisme, avec sqlserver par exemple.

Si ton appli est une appli asp.net alors il n'y a qu'un processus pour tous tes clients, et le lock fonctionne comme tu le souhaites puisqu'il empechera deux threads d'exécuter en même temps ton code.

[jbrasselet]

C'est bien une appli ASP.Net donc cela fonctionne comme je le désire.
Merci des précisions sur les définitions des utilisateurs et threads.