Discussion :

[nic2t]

Bonjour à tous,

Étant étudiant en alternance, il me manque un peu d'expérience sur certaines architectures...
Je sollicite donc votre aide.

Mon problème :

Nous avons une application lourde en java.
Cette application est critique car au delà de la sauvegarde des données dans une base de données, elle effectue des traitements dans notre usine : qualification et disqualification de process.

En choisissant 3 critères, nous créons une table temporaire via d'autres tables.
Ensuite il est possible de faire des updates, delete sur d'autres tables par rapport aux données qui sont dans cette table temporaire.

Cependant, il est possible que deux personnes se connectent simultanément sur les 3 mêmes critères (sinon ça ne pose pas de problème).
Dans ce cas là, si 2 updates, deletes ou ajout d'informations cela nous posent des problèmes d'intégrités (pas de problème coté usine).

On voudrait, en fait, juste bloquer l'accès lorsqu'une personne essaie de se connecter à l'application avec les 3 mêmes critères qu'une autre personne déja connectée.

On a pensé à faire un flag en DB : lorsqu'une personne se connecte on met les 3 criteres a false, et lorsqu'elle se deconnecte on remet à true.
Mais ça risque de poser une problème si par exemple, cette personne se loggue et éteint brutalement son ordi sans passer par la case delogging.

Peut être est possible uniquement en utilisant l'isolation des données fourni par JDBC, mais je ne suis pas très sur de moi...

Avez vous des solutions à proposer ?

Cordialement,
Nicolas

[Génoce]

On a pensé à faire un flag en DB : lorsqu'une personne se connecte on met les 3 criteres a false, et lorsqu'elle se deconnecte on remet à true.
Mais ça risque de poser une problème si par exemple, cette personne se loggue et éteint brutalement son ordi sans passer par la case delogging.

Bonjour,

Pourquoi ne pas mettre en place un timeout, au bout d'un temps donné, tu déverrouilles.

Par isolation des données JDBC tu penses aux mutex / verrous?
C'est probablement le plus propre.

Cela dit je ne suis pas expert !

[nic2t]

Si je mets un timeout, je dois le mettre coté serveur, je pense.
ça me parait être une bonne idée, mais je vois pas trop comment la mettre en place.

Et à part un serveur de base de données, on a rien : c'est une application lourde...

Peut être pourrait on faire tourner un script qui check mais ça parait trop lourd comme solution...

En parlant d'isolation, je parlais des différents niveau d'isolation pour les accès concurrents, mais je sais pas vraiment s'ils s'appliquent dans ces cas là (il me semble que c'est entre le start transaction et le commit/rollback).

Le verrous est une bonne idée aussi, mais peut on locker qu'une seule partie de la table... je ne sais pas du tout.
Et si on arrive à locker une partie de la table, l'application plante pour une raison quelconque, comment la re déverrouiller ?

Merci pour ton aide.

Nicolas

[Génoce]

Le verrous est une bonne idée aussi, mais peut on locker qu'une seule partie de la table... je ne sais pas du tout.
Et si on arrive à locker une partie de la table, l'application plante pour une raison quelconque, comment la re déverrouiller ?

Merci pour ton aide.

Nicolas

Je ne sais pas si on peut verrouiller ligne par ligne dans une table mais c'est fort probable.
Je pense que la bdd gère un timeout, ou quelque autre mécanisme qui permet de déverrouiller.

Ce sont uniquement des suppositions, essaie de faire une recherche ou poste dans le forum SGBD concerné.

[Alkhan]

bonjour,

Je ne sais pas si on peut verrouiller ligne par ligne dans une table mais c'est fort probable.

En effet, il suffit d'utiliser une instruction du genre "Select ... For Update".
Cette instruction n'existe peut etre pas sur toutes les base de données.

cela permet de locker une ou plusieurs ligne selon le critère.

[nic2t]

En y réfléchissant plus sérieusement, je pense que l'on ne peut pas utiliser le blocage de quelques lignes.

Le soucis vient du fait que les lignes de l'écran n°1 proviennent d'une succession de requêtes qui forment une table temporaire.

Admettons que deux personnes se connectent au même moment selon les trois critères.
Elles chargent chacun leur écran de ligne de process via une table temporaire chacune (une par user) (en passant si on pouvait faire une table temporaire par série de 3 critères, le problème serait réglé mais c'est trop couteux en temps je pense...)

Une fois que toutes les lignes sont chargées, le user A décide de disqualifier un process.
Si le user B décide lui aussi de disqualifier ce process, cela va poser un problème au niveau de l'usine.

Cependant même si on lock la table le temps de la transaction du user A.
Le user B a quand même les mauvaises données car il utilise une table temporaire faite de données qui ne sont plus à jour.

La solution est de bloquer l'accès complet à la selection de 3 critères.
C'est la seule que je pense envisageable.

Du coup, il faut une valeur qui soit toujours à false, et qui passe à true pendant 15 minutes par exemple.
Mais c'est trés contraignant : la personne ne pourra se logger que 15 minutes ou si le user veut disqualifier un process dangereux et qu'il plante, il faudra attendre 15 minutes pour pouvoir le disqualifier.

Au delà de la technique, j'ai vraiment du mal à trouver une solution conceptuelle...

[Génoce]

Je suis perdu

[Alkhan]

j'imagine que la table temporaire de 3 critères à un nom unique s'il en existe une pour chaque utilisateur avec les même 3 critère !

Dans ce cas pourquoi ne pas créer une table temporaire dont le nom est lié au 3 critères ? De cette façon lorsque deux utilisateurs ont les mêmes critères la table sera créé pour le premier et le deuxième lui ne pourra pas (tu recevra une exception lié au fait que la table existe déjà), ce qui l'empêchera de se connecter avec ces critères là.

[Génoce]

Donc c'est bon?

Une seule personne à la fois peut réaliser l'opération.

Par contre comment libérer le schmilblik si la personne qui à verrouiller plante? Tu es parti sur quelque chose?

[tchize_]

normalement c'est le role de l'isolation des transactions ce genre de bazar, inutile de réinventer la roue. Tu demande à ton connecteur un niveau d'isolation (typiquement dans ton cas, l'isolation SERIALIZABLE) et tu fais tout comme un grand dans UNE SEULE transaction . En cas d'accès concurrent, si quelqu'un modifie les même données que toi ou des données sur lequelles tu aurait pu te baser, la deuxième personne à sauver aura une erreur lors du commit (à cause de l'isolation) et ses changements ne seront pas effectués. Exemple avec deux utilisateurs qui sont sur les même critère dans deux cas typique:

A: début de transaction
A: récupère la ligne 5 (valeur A) et l'affiche à l'écran
B: début de transaction
B: récupère les lignes 5 (valeur A),6 (valeur B) et 7 (valeur C) et les affiche à l'écran
B: efface les lignes 5 et 6, et change la ligne 7 (valeur C2) (par exemple, 3 demandes de process industriel regroupées par un opérateur en une seule dans la ligne 7)
A: modifie la ligne 5 (valeur A2) (par exemple, changement des spécifications demandées par le client)
A: sauve (commit) -> ok
B: sauve (commit)-> erreur, rollback, changements annulé
B: nouvel affichage
B: récupère les lignes 5 (valeur A2),6 (valeur B) et 7 (valeur C)
B: efface la ligne 6 et change la 7 (valeur C2) (seulement deux process à réunir au final)
B: sauve (commit) -> ok

A: début de transaction
A: récupère la ligne 5 (valeur A) et l'affiche à l'écran
B: début de transaction
B: récupère les lignes 5 (valeur A),6 (valeur B) et 7 (valeur C) et les affiche à l'écran
B: efface les lignes 5 et 6, et change la ligne 7 (valeur C2) (par exemple, 3 demandes de process industriel regroupées par un opérateur en une seule dans la ligne 7)
A: modifie la ligne 5 (valeur A2) (par exemple, changement des spécifications demandées par le client)
B: sauve (commit) -> ok
A: sauve (commit)-> erreur, rollback, changements annulé
A: nouvel affichage
B: récupère la ligne 5 (n'existe plus)
B: "désolé monsieur, vos trois commandes sont déjà envoyées en production, je ne peux plus les changer"
B: rien à sauver (rollback) -> ok

Il faut bien sur être rigoureux dans ton code et ne faire entrer dans ta transaction aucune information qui proviendrais d'une requête faite dans une transaction précédente. Les select for update ne sont pas nécessaire dans ce cas (sous oracle en tout cas), puisque c'est au moment du commit que le SGDB va voir que, dans ta transaction, tu a lu des données qui depuis ont changé, ce qui rend impossible de garantir les contraintes du "SERIALIZABLE".

[nic2t]

Bonjour !

Génoce tu dis être perdu, j'avoue que je m'exprime pas très bien, et si t'as bloqué quelques part n'hésite pas a me demandé d'expliquer, pour moi ça me parait simple parce que je travaille dessus mais ça doit pas être facile pour vous.

Alkan, notre DB est sous informix et ,je sais pas si c'est possible de le faire sur d'autres bases mais chaque table temporaire est créé dans la session d'un utilisateur.

Peut être est il possible de changer ce mode de fonctionnement et de créer une table temporaire avec comme nom les 3 critères uniques.
Cependant, pour moi ça ne change pas trop le problème...

Soit on crée cette table qui aura comme nom les 3 critères, et lorsqu'un user se connecte, on vérifie si elle existe et si elle existe on se log pas : mais la on a toujours le problème de comment supprimer cette table si le user déja connecté plante.

Soit on crée aussi une table avec les 3 critères.
Un user A se log, ça créé la table.
Le user B se loggue aussi.
Le user A disqualifie un process, il regénère la table, et il a les bonnes données.
B regarde son écran et il pense que le process est qualifié, il veut aussi le disqualifier, et pouf, erreur.

Dans tous les cas, je pense qu'il faut autoriser qu'un seul user par triplette.
Mais je ne vois pas comment arriver à ce blocage...

Merci à vous !
Nicolas

[nic2t]

Merci Tchize, je pense effectivement que c'est la meilleure solution.
Notre niveau d'isolation est dirty read et effectivement, on ne bloque rien.

Si 100 personnes utilisent l'application, l'utilisation du sérializable ne bloque pas la table, elle bloque uniquement les lignes en cours de modifications, c'est ça ?

Actuellement le processus est fait comme ça :

1 on choisit nos critères.
2 on génération des tables
3 affichage
4 selection du process a disqual/qual
5 saisi de la raison
6 validation -> et c'est à ce moment que se fait notre commit

il faut être sur que :

A choisit ses criteres
B choisit les mêmes critères
A B : génération des mêmes tables
A B : affichage des mêmes données et start de la transaction alors
A selectionne le process et saisi la raison
B fait la même chose
A valide : ok ça marche
B valide : trop tard tu rollback.

ça me parait être la meilleur solution, je vais commencer à l'implémenter en intégration la semaine prochaine et la présenter à mon tuteur et on verra si c'est faisable ou si les contraintes de notre système nous empêche de fonctionner ainsi.

Je vous tiendrais au courant.

Merci pour tout, bonne journée !

Nicolas

[tchize_]

Merci Tchize, je pense effectivement que c'est la meilleure solution.
Notre niveau d'isolation est dirty read et effectivement, on ne bloque rien.

Si 100 personnes utilisent l'application, l'utilisation du sérializable ne bloque pas la table, elle bloque uniquement les lignes en cours de modifications, c'est ça ?

le dirty read, comme son nom l'indique, te permet de voir des mauvaises données (mais est moins bloquant), dans ton cas, il n'est pas approprié. Le serializable ne devrait pas bloquer toute la table, seulement les lignes concernée, mais en réalité c'est laissé à l'appréciation du SGDB. Rien n'empeche le SGDB de t'envoyer péter pour de mauvaise raison, l'important est qu'il ne t'aie pas laissé faire quelque chose d'interdit.

De mon expérience avec oracle, c'est bien géré au niveau des lignes. Le problème du select for update, c'est qu'il lock la ligne même quand ça n'est pas nécessaire et le fait tôt. Avec l'isolation de transaction, une transaction sur laquelle on fait au final un rollback ou un opérateur qui est parti prendre sa pose déjeuner ne bloque pas tout le monde en ayant un row locké .

Dans ton cas, j'afficherais la liste complète avec une transaction ou hors transaction, et quand on clique sur un élément à changer, j'entamerais une transaction au cours de laquelle je redemanderais la ligne à la DB puis présentrais à l'opérateur ses options de travail dessus et à la fin de ses opérations ferait le commit.