Accès concurrents FireBird

Version imprimable

22/02/2016, 12h25
Francis

Accès concurrents FireBird

Bonjour,
Sous Delphi Xe2 , Fire Bird 2.5 (64 Bits) Windows 7 Entreprise , j'ai écrit un programme tout simple qui lit une Table FireBird
(Matricule, Nom, Prenom) Avec un bouton Update
Si le matricule n'existe pas je fais un Insert sinon je Fais un Edit
Je fais le Post et juste après je fais le Commit
Sur un seul poste ça marche sans problème quelque soit l'emplacement de la Base sous réseaux.
1- Par contre en version réseaux ,deux postes seulement , aucun PC ne voit les mises à jour faites par l'autre PC.
C'est comme si chaque PC travaillait sur une copie de la BDD. Quand je quitte le programme et je le relance, je vois les modifications
faites par l'autre poste. Même en faisant Table.Close et Table.Open ça ne marche pas .
Comment régler ce problème. Merci d'éclairer ma lanterne.

2- Comment verrouiller un enregistrement d'une Table FireBird?
22/02/2016, 14h47
SergioMaster

Bonjour,

Citation:

1- Par contre en version réseaux ,deux postes seulement , aucun PC ne voit les mises à jour faites par l'autre PC.
C'est comme si chaque PC travaillait sur une copie de la BDD. Quand je quitte le programme et je le relance, je vois les modifications
faites par l'autre poste. Même en faisant Table.Close et Table.Open ça ne marche pas .

c'est un des problèmes des tables (ou des DBGrids), dès que l'on lit plus d'un enregistrement on travaille sur une copie de table.
Faire un Open/Close par contre devrait fonctionner, le tout est de savoir quand faire ce rafraichissement !
pour cela il faudra passer par les EVENTS (encore heureux cela existe avec Interbase et Firebird) j'ai traduit un article à ce sujet il y a peu

Citation:

2- Comment verrouiller un enregistrement d'une Table FireBird?

avec tels types de composants Delphi ?
avec une requête voir cette lecture
23/02/2016, 10h02
Francis

J'utilise des composants Ibtables, car c'est une application que j'ai fait Migrer du Paradox sous BDE vers FireBird, pensant qu'avec FireBird
tout serait plus simple.

1- J'ai lu avec grand intérêt l'article relatif aux événements. J'ai fait des tests le PC2 doit faire obligatoirement un commit pour
voir les modifications faites par le PC1. Comme le Commit ferme les Tables, il faut les rouvrir , se positionner sur les enregistrements en cours pour pouvoir continuer le traitement sans problème. Résultat je passe mon temps à Faire des IbTable.Open après les commit
inscrits au niveau des Evénements. Je pense que la Bande Passante va être surchargée avec cette solution.

2- Pour les Verrous , je suis resté sur ma faim .
3- On parle du <TPB mode> où le modifier
Merci par avance
23/02/2016, 11h14
SergioMaster

Bonjour,

je n'ai jamais utilisé les IBxxxxx donc je n'ai pas de solution claire à ce sujet, de plus la question, s'il y a, concerne plus le forum Delphi/Base de Données que Firebird .

en fait ceci

Citation:

J'ai fait des tests le PC2 doit faire obligatoirement un commit pour
voir les modifications faites par le PC1. Comme le Commit ferme les Tables, il faut les rouvrir , se positionner sur les enregistrements en cours pour pouvoir continuer le traitement sans problème.

m'étonne et je pense qu'il y a là un problème de mode d'accès

Quelques pistes toutefois : Quels sont les params de la transaction, et toujours pour la transaction la valeur de DefaultAction ?
les plus "classiques" étant

Citation:

read_committed
rec_version
nowait

et TACommit
c'est certainement là dessus qu'il faut jouer pour les verrous et pour ce Commit à faire suivi d'une fermeture

pour ce qui est des EVENTS par contre non je ne pense pas que cela surchargera la bande passante , sauf si bien sur les tables sont énormes, mais dans ce cas on n'ouvre pas une table ;) on fait des requêtes plus "ciblées"

pour les IBTable(s) voir aussi les méthodes Refresh et Resync (mais cela reste des problèmes Delphi pas Firebird)
23/02/2016, 21h00
Artemus24

Salut à tous.

Citation:

Envoyé par Francis

aucun PC ne voit les mises à jour faites par l'autre PC.

Logiquement pour faire une mise à jour, je procède ainsi :

1) je verrouille la page où se trouve ma ligne. Si la demande est accepté alors je poursuis, sinon arrêt (cela signifie qu'une autre personne monopolise la page=.
2) je lis la ligne.
3) je modifie ma ligne.
4) je valide par un commit.
5) je déverrouille ma page.

Dès que la page est déverrouillée, normalement la modification devrait être vu par l'autre PC.
A un instant donné, il y a une seule modification possible sur une page, sinon on se retrouve dans un dead lock.

Je ne suis pas assez expert sur FireBird, mais il doit exister un paramétrage sur les accès concurrents.
Il faudrait voir ce qui se fait et comment solutionner ce genre de problème.

@+
24/02/2016, 08h43
SergioMaster

Bonjour,

ta procédure Artemus24 est valable pour un enregistrement pas pour la table entière.

pour donner un exemple moins théorique :

Soit un fichier de personnes à contacter et plusieurs téléopérateurs, chaque téléopérateur à devant les yeux la liste des personnes à contacter, chaque fois qu'un opérateur sélecte une personne les autres doivent voir qu'un de leur collègue s'en charge et donc en prendre un autre. Cela implique que la liste (table) affichée sur les postes doit être mise à jour dès qu'un opérateur fait une action.

Or ceci, dans un programme Delphi (ou autre je pense) ne se déclenche pas tout seul !

Un moyen est de gérer les EVENEMENTS (encore heureux peu de SGBD propose une telle chose), cependant sur une grosse table ouverte en entier, il y aura trop de trafic. Un des moyens de diminuer ce dernier est alors de ne proposer à l'affichage qu'une partie (la notion de page)
(ROWS <from> FOR <number> ou FIRST <number> SKIP <from> d'une requête SELECT) alors c'est si et seulement si l'enregistrement fait partie de la "tranche récupérée" que la requête sera rafraichie. Reste quand même alors une autre étape à franchir : comment savoir si l'enregistrement fait partie du panel affiché car un EVENT n'a pas de paramètres supplémentaires.

je m'arrête là car j'ai l'impression de déjà écrit dans une autre discussion sans parler de l'article déjà cité
24/02/2016, 17h27
Artemus24

Salut Sergiomaster.

Citation:

Envoyé par Sergiomaster

ta procédure Artemus24 est valable pour un enregistrement pas pour la table entière.

C'est complétement aberrant de bloquer une table, juste pour modifier une ligne de la table.
Et d'ailleurs, je n'ai ni parlé de ligne, ni de table mais de page.
La page est la plus petite entité physique sur un disque où l'on pratique des lectures et des écritures.

Citation:

Envoyé par Sergiomaster

Or ceci, dans un programme Delphi (ou autre je pense) ne se déclenche pas tout seul !

Tout à fait d'accord, sauf que c'est le premier qui verrouille la page, prendra à sa charge les modifications à faire.
Les autres peuvent encore lire la ligne, mais ne pourront pas modifier les lignes de la page bloquée.
Cela permet de ne pas pénaliser les autres intervenants sur la table, enfin pour les autres pages.

J'ai l'impression en te lisant que la notion d'évènement n'est pas identique à MySql.
Là, je ne comprends pas bien où tu veux en venir.

La notion qui permet de gérer les problèmes de conccurence sous MySql est :

Code:

transaction-isolation

Je prends cet article (en français) qui détail la signification de ce paramètre mais sous Microsoft sql server.
--> https://msdn.microsoft.com/fr-fr/lib...=sql.120).aspx

Voici pour FireBird :
--> http://www.firebirdsql.org/manual/is...nsactions.html
--> http://www.firebirdsql.org/refdocs/l...set-trans.html

@+
25/02/2016, 08h46
SergioMaster

Bonjour,

@Artemus encore une fois on ne parle pas de la même chose.

il y a transaction, j'ai d'ailleurs déjà indiqué cette piste de travail
et la notion de table (IBTable Delphi) affichée, quand j'ai parlé de page ou de ligne je faisais référence à la page affichée et non à la

Citation:

page : plus petite entité physique sur un disque où l'on pratique des lectures et des écritures.

pour reprendre l'exemple :
2 téléopérateurs ouvre le programme qui affiche une liste des numéros à appeler dans une grille ils ont donc la même liste positionnée au même endroit (début de table)
le 1° téléopérateur sélectionne le premier numéro => le second (parti boire un café) doit voir sa liste se modifier, passage de la ligne affichée en rouge par exemple puis en vert si l'appel a été fait et la personne contactée ou en orange s'il faut rappeler plus tard.
effectivement le mode de transaction peut gérer le blocage de l'enregistrement si l'opérateur 2 sélectionne le même numéro mais en aucun cas il n'y a possibilité de gérer l'affichage, sauf à passer par la notion d'évènements

il en va de même si un opérateur insère un nouveau numéro, la table ouverte par le programme ne se rafraichira pas d'elle même
25/02/2016, 11h56
Francis

Problème de verrou sous FireBird

Bonjour,
Après plusieurs essais le problème de verrou est résolu si le Composant IbTransaction est paramétré à:
< Concurrency & nowait>
FireBird vérifie si l'enregitrement en mise à jour n'a pas été modifié par un autre utilisateur entre temps. Ceci s'avére très intéresant sans
trop de code il suffit de récupérer l'Exception après un Post.
If affiche le message : <deadlock update conflicts with concurrent update>
Il suffit d'envoyer un message à l'utilisateur et de relire l'enregistrement.

Reste le problème des performances à surveiller.
25/02/2016, 20h45
Artemus24

Salut à tous.

Citation:

Envoyé par SergioMaster

encore une fois on ne parle pas de la même chose.

Ah bon ? :?

Citation:

Envoyé par Francis

Après plusieurs essais le problème de verrou est résolu si le Composant IbTransaction est paramétré à:< Concurrency & nowait>

Si ton problème est résolu alors tout va bien.

Citation:

Envoyé par Francis

FireBird vérifie si l’enregistrement en mise à jour n'a pas été modifié par un autre utilisateur entre temps.

C'est cette affirmation que je ne comprends pas.
Quand on veut modifier une ligne, la première des choses à faire, lors de la lecture, c'est de bloquer la ligne.
Cette demande est soit acceptée, soit rejetée (oui car un autre intervenant l'a déjà fait).

Si la demande est acceptée, alors on peut modifier la ligne sans aucun soucis, même si entre temps, tu vas pisser, manger à la cafétéria ou je ne sais quoi d'autre.
Le seul inconvénient, c'est que tu pénalises les autres intervenants car ils ne peuvent plus intervenir sur cette ligne.

Dans ton explication, tu lis sans faire de blocage.
De ce fait, lors de la modification, tu dois à nouveau te poser la question sur cette ligne qui peut avoir été modifié entre temps.
Si elle a été modifiée entre temps alors ta demande de modification sera rejeté.
Et de ce fait, tu dois recommencer l'opération.

C'est pourquoi, le mode transactionnel doit être sérialisé afin de ne pas rencontrer ces problèmes de conflits d'accès.

@+