Comment faites-vous (bases de données)

William Dode

07/08/2008 à 11:37

On 07-08-2008, Méta-MCI (MVP) wrote:

Bonjour !

Je vais prendre un exemple simple.

Des (lignes de) factures.
On prend une facture, qui contient 10 lignes, chacune avec un numéro de
ligne, un code article, une quantité.
L'utilisateur veut modifier cette facture. Il va donc rapatrier les 10
lignes, faire ses modifications, renvoyer le tout.

Mais, cela pose d'énormes problèmes. Ainsi, si vous êtes en verrouillage
pessimiste, comment éviter les verrous résiduels ?

Quels verrous résiduels ?

Si vous êtes en verrouillage optimiste, comment gérer une simple
suppression d'une ligne, dans l'ensemble des 10 lignes ? Et comment
gérer les conflits d'accès ?

Tu parles au niveau programme ou au niveau utilisateur ?

Au niveau programme, je met un verrou sur l'entête dès qu'il y a la
moindre modification à venir sur une des lignes

--
William Dodé - http://flibuste.net
Informaticien Indépendant

Méta-MCI (MVP)

07/08/2008 à 17:42

Re !

D'abord, merci d'avoir répondu.

Quels verrous résiduels ?

En verrouillage pessimiste, on pose les verrous (sur le serveur de base
de données) avant toute opération, et on les enlève, une fois la
transaction terminée.
Mais, si le poste qui verrouille est brutalement éteint (coupure de
courant, ou déconnexion intempestive, par exemple), les verrous restent.
C'est cela, que j'appelle verrou résiduel.
A noter que, si le serveur gère lui-même les verrous, il ne peut pas
savoir si le poste est vraiment coupé (verrous à supprimer), ou s'il est
simplement en veille (verrous à conserver). De plus, quels sont les
serveurs de base de données qui gèrent bien les verrous ?

je met un verrou sur l'entête dès qu'il y a la moindre modification à
venir sur une des lignes

Donc, verrouillage pessimiste. Le problème du verrouillage pessimiste
par en-têtes, c'est la cascade inverse. Si on va modifier une ligne de
facture, il faut, bien sûr, poser un verrou sur l'en-tête ; mais aussi
sur l'article, le client, l'établissement, etc. (pour cause d'intégrité
référentielle).
Si, par exemple lorsqu'un utilisateur veut faire une modification sur un
article très utilisé, dès que l'on aura plus de 5 ou 6 postes qui
facturent, la modif sera impossible, car toujours verrouillé par
quelqu'un d'autre.
Ou alors, il faut spécialiser les verrous, jusqu'au niveau des champs...
(bonjour l'usine à gaz).

En fait, j'ai un problème, pour un logiciel que j'avais développé en
Paradox, et que je voudrais ré-écrire en Python. C'est un logiciel
spécifique, dans le domaine de la santé. Ce logiciel est utilisé
24h./24h., par un nombre de postes variant de 6 à 50 (simultanément).
Avec Paradox, le verrouillage (pessimiste) est réalisé automatiquement
au niveau de chaque ligne, ce qui réduit les interactions, car dès qu'un
utilisateur change de ligne, les verrous sont relâchés. Mais, cela veut
dire que l'on n'a qu'une seule ligne à la fois (quoique, si Paradox n'a
qu'une ligne en modif, il a les autres en visu seule, avec, en plus, un
rafraîchissement automatique, toutes les 6 secondes).

J'ai bien quelques idées tordues, mais elles ne passent pas tous les
cas.

@+

Michel Claveau

Re !

D'abord, merci d'avoir répondu.

Quels verrous résiduels ?

En verrouillage pessimiste, on pose les verrous (sur le serveur de base
de données) avant toute opération, et on les enlève, une fois la
transaction terminée.
Mais, si le poste qui verrouille est brutalement éteint (coupure de
courant, ou déconnexion intempestive, par exemple), les verrous restent.
C'est cela, que j'appelle verrou résiduel.
A noter que, si le serveur gère lui-même les verrous, il ne peut pas
savoir si le poste est vraiment coupé (verrous à supprimer), ou s'il est
simplement en veille (verrous à conserver). De plus, quels sont les
serveurs de base de données qui gèrent bien les verrous ?

je met un verrou sur l'entête dès qu'il y a la moindre modification à
venir sur une des lignes

Donc, verrouillage pessimiste. Le problème du verrouillage pessimiste
par en-têtes, c'est la cascade inverse. Si on va modifier une ligne de
facture, il faut, bien sûr, poser un verrou sur l'en-tête ; mais aussi
sur l'article, le client, l'établissement, etc. (pour cause d'intégrité
référentielle).
Si, par exemple lorsqu'un utilisateur veut faire une modification sur un
article très utilisé, dès que l'on aura plus de 5 ou 6 postes qui
facturent, la modif sera impossible, car toujours verrouillé par
quelqu'un d'autre.
Ou alors, il faut spécialiser les verrous, jusqu'au niveau des champs...
(bonjour l'usine à gaz).

En fait, j'ai un problème, pour un logiciel que j'avais développé en
Paradox, et que je voudrais ré-écrire en Python. C'est un logiciel
spécifique, dans le domaine de la santé. Ce logiciel est utilisé
24h./24h., par un nombre de postes variant de 6 à 50 (simultanément).
Avec Paradox, le verrouillage (pessimiste) est réalisé automatiquement
au niveau de chaque ligne, ce qui réduit les interactions, car dès qu'un
utilisateur change de ligne, les verrous sont relâchés. Mais, cela veut
dire que l'on n'a qu'une seule ligne à la fois (quoique, si Paradox n'a
qu'une ligne en modif, il a les autres en visu seule, avec, en plus, un
rafraîchissement automatique, toutes les 6 secondes).

J'ai bien quelques idées tordues, mais elles ne passent pas tous les
cas.

@+

Michel Claveau

Vous avez filtré cet utilisateur ! Consultez son message

Re !

D'abord, merci d'avoir répondu.

Quels verrous résiduels ?

En verrouillage pessimiste, on pose les verrous (sur le serveur de base
de données) avant toute opération, et on les enlève, une fois la
transaction terminée.
Mais, si le poste qui verrouille est brutalement éteint (coupure de
courant, ou déconnexion intempestive, par exemple), les verrous restent.
C'est cela, que j'appelle verrou résiduel.
A noter que, si le serveur gère lui-même les verrous, il ne peut pas
savoir si le poste est vraiment coupé (verrous à supprimer), ou s'il est
simplement en veille (verrous à conserver). De plus, quels sont les
serveurs de base de données qui gèrent bien les verrous ?

je met un verrou sur l'entête dès qu'il y a la moindre modification à
venir sur une des lignes

Donc, verrouillage pessimiste. Le problème du verrouillage pessimiste
par en-têtes, c'est la cascade inverse. Si on va modifier une ligne de
facture, il faut, bien sûr, poser un verrou sur l'en-tête ; mais aussi
sur l'article, le client, l'établissement, etc. (pour cause d'intégrité
référentielle).
Si, par exemple lorsqu'un utilisateur veut faire une modification sur un
article très utilisé, dès que l'on aura plus de 5 ou 6 postes qui
facturent, la modif sera impossible, car toujours verrouillé par
quelqu'un d'autre.
Ou alors, il faut spécialiser les verrous, jusqu'au niveau des champs...
(bonjour l'usine à gaz).

En fait, j'ai un problème, pour un logiciel que j'avais développé en
Paradox, et que je voudrais ré-écrire en Python. C'est un logiciel
spécifique, dans le domaine de la santé. Ce logiciel est utilisé
24h./24h., par un nombre de postes variant de 6 à 50 (simultanément).
Avec Paradox, le verrouillage (pessimiste) est réalisé automatiquement
au niveau de chaque ligne, ce qui réduit les interactions, car dès qu'un
utilisateur change de ligne, les verrous sont relâchés. Mais, cela veut
dire que l'on n'a qu'une seule ligne à la fois (quoique, si Paradox n'a
qu'une ligne en modif, il a les autres en visu seule, avec, en plus, un
rafraîchissement automatique, toutes les 6 secondes).

J'ai bien quelques idées tordues, mais elles ne passent pas tous les
cas.

@+

Michel Claveau

William Dode

07/08/2008 à 19:56

On 07-08-2008, Méta-MCI wrote:

Re !

D'abord, merci d'avoir répondu.

Quels verrous résiduels ?

En verrouillage pessimiste, on pose les verrous (sur le serveur de base
de données) avant toute opération, et on les enlève, une fois la
transaction terminée.
Mais, si le poste qui verrouille est brutalement éteint (coupure de
courant, ou déconnexion intempestive, par exemple), les verrous restent.
C'est cela, que j'appelle verrou résiduel.
A noter que, si le serveur gère lui-même les verrous, il ne peut pas
savoir si le poste est vraiment coupé (verrous à supprimer), ou s'il est
simplement en veille (verrous à conserver). De plus, quels sont les
serveurs de base de données qui gèrent bien les verrous ?

Postgresql surement.
http://docs.postgresqlfr.org/8.3/mvcc.html

Si le poste est déconnecté brutalement la connexion à la base de données
va automatiquement être coupée et la transaction et les verrous annulés.

je met un verrou sur l'entête dès qu'il y a la moindre modification à
venir sur une des lignes

Donc, verrouillage pessimiste. Le problème du verrouillage pessimiste
par en-têtes, c'est la cascade inverse. Si on va modifier une ligne de
facture, il faut, bien sûr, poser un verrou sur l'en-tête ; mais aussi
sur l'article, le client, l'établissement, etc. (pour cause d'intégrité
référentielle).
Si, par exemple lorsqu'un utilisateur veut faire une modification sur un
article très utilisé, dès que l'on aura plus de 5 ou 6 postes qui
facturent, la modif sera impossible, car toujours verrouillé par
quelqu'un d'autre.
Ou alors, il faut spécialiser les verrous, jusqu'au niveau des champs...
(bonjour l'usine à gaz).

Ca se fait il parait, mais faut vraiment en avoir l'utilité !
J'ai l'impression que tu mélange les problèmes de verrous au niveau base
de données et les verrous utilisateurs. Pour le côté base de données, je
ne vois pas le problème de poser un verrou très large vu que l'opération
va être instantanée et dans une transaction.

Enfin bref, j'essaye de ne pas mélanger les deux, cad que je n'utilise
pas les verrous BD pour verrouiller les utilisateurs mais des verrous
plus souples disons, avec timer éventuellement.
Pour les factures par ex, pas forcément besoin d'un verrou utilisateur
vu qu'on est obligé de copier toutes les données articles et clients,
peu importe s'ils changent pendant qu'on fait la saisie. C'est du cas
par cas quoi.

En fait, j'ai un problème, pour un logiciel que j'avais développé en
Paradox, et que je voudrais ré-écrire en Python. C'est un logiciel
spécifique, dans le domaine de la santé. Ce logiciel est utilisé
24h./24h., par un nombre de postes variant de 6 à 50 (simultanément).
Avec Paradox, le verrouillage (pessimiste) est réalisé automatiquement
au niveau de chaque ligne, ce qui réduit les interactions, car dès qu'un
utilisateur change de ligne, les verrous sont relâchés. Mais, cela veut
dire que l'on n'a qu'une seule ligne à la fois (quoique, si Paradox n'a
qu'une ligne en modif, il a les autres en visu seule, avec, en plus, un
rafraîchissement automatique, toutes les 6 secondes).

Ok, je comprend pourquoi tu mélange interface et bdd... Je raisonne
plutôt en terme d'appli web, donc sans lien direct entre l'interface et
le moteur.
Sur le wikipython par ex, quand un utilisateur modifie une page le
verrou tien un certain temps, faut faire des aperçus pour le conserver
plus longtemps.

J'ai bien quelques idées tordues, mais elles ne passent pas tous les
cas.

--
William Dodé - http://flibuste.net
Informaticien Indépendant

On 07-08-2008, Méta-MCI wrote:

Re !

D'abord, merci d'avoir répondu.

Quels verrous résiduels ?

En verrouillage pessimiste, on pose les verrous (sur le serveur de base
de données) avant toute opération, et on les enlève, une fois la
transaction terminée.
Mais, si le poste qui verrouille est brutalement éteint (coupure de
courant, ou déconnexion intempestive, par exemple), les verrous restent.
C'est cela, que j'appelle verrou résiduel.
A noter que, si le serveur gère lui-même les verrous, il ne peut pas
savoir si le poste est vraiment coupé (verrous à supprimer), ou s'il est
simplement en veille (verrous à conserver). De plus, quels sont les
serveurs de base de données qui gèrent bien les verrous ?

Postgresql surement.
http://docs.postgresqlfr.org/8.3/mvcc.html

Si le poste est déconnecté brutalement la connexion à la base de données
va automatiquement être coupée et la transaction et les verrous annulés.

je met un verrou sur l'entête dès qu'il y a la moindre modification à
venir sur une des lignes

Donc, verrouillage pessimiste. Le problème du verrouillage pessimiste
par en-têtes, c'est la cascade inverse. Si on va modifier une ligne de
facture, il faut, bien sûr, poser un verrou sur l'en-tête ; mais aussi
sur l'article, le client, l'établissement, etc. (pour cause d'intégrité
référentielle).
Si, par exemple lorsqu'un utilisateur veut faire une modification sur un
article très utilisé, dès que l'on aura plus de 5 ou 6 postes qui
facturent, la modif sera impossible, car toujours verrouillé par
quelqu'un d'autre.
Ou alors, il faut spécialiser les verrous, jusqu'au niveau des champs...
(bonjour l'usine à gaz).

Ca se fait il parait, mais faut vraiment en avoir l'utilité !
J'ai l'impression que tu mélange les problèmes de verrous au niveau base
de données et les verrous utilisateurs. Pour le côté base de données, je
ne vois pas le problème de poser un verrou très large vu que l'opération
va être instantanée et dans une transaction.

Enfin bref, j'essaye de ne pas mélanger les deux, cad que je n'utilise
pas les verrous BD pour verrouiller les utilisateurs mais des verrous
plus souples disons, avec timer éventuellement.
Pour les factures par ex, pas forcément besoin d'un verrou utilisateur
vu qu'on est obligé de copier toutes les données articles et clients,
peu importe s'ils changent pendant qu'on fait la saisie. C'est du cas
par cas quoi.

En fait, j'ai un problème, pour un logiciel que j'avais développé en
Paradox, et que je voudrais ré-écrire en Python. C'est un logiciel
spécifique, dans le domaine de la santé. Ce logiciel est utilisé
24h./24h., par un nombre de postes variant de 6 à 50 (simultanément).
Avec Paradox, le verrouillage (pessimiste) est réalisé automatiquement
au niveau de chaque ligne, ce qui réduit les interactions, car dès qu'un
utilisateur change de ligne, les verrous sont relâchés. Mais, cela veut
dire que l'on n'a qu'une seule ligne à la fois (quoique, si Paradox n'a
qu'une ligne en modif, il a les autres en visu seule, avec, en plus, un
rafraîchissement automatique, toutes les 6 secondes).

Ok, je comprend pourquoi tu mélange interface et bdd... Je raisonne
plutôt en terme d'appli web, donc sans lien direct entre l'interface et
le moteur.
Sur le wikipython par ex, quand un utilisateur modifie une page le
verrou tien un certain temps, faut faire des aperçus pour le conserver
plus longtemps.

J'ai bien quelques idées tordues, mais elles ne passent pas tous les
cas.

--
William Dodé - http://flibuste.net
Informaticien Indépendant

Vous avez filtré cet utilisateur ! Consultez son message

On 07-08-2008, Méta-MCI wrote:

Re !

D'abord, merci d'avoir répondu.

Quels verrous résiduels ?

En verrouillage pessimiste, on pose les verrous (sur le serveur de base
de données) avant toute opération, et on les enlève, une fois la
transaction terminée.
Mais, si le poste qui verrouille est brutalement éteint (coupure de
courant, ou déconnexion intempestive, par exemple), les verrous restent.
C'est cela, que j'appelle verrou résiduel.
A noter que, si le serveur gère lui-même les verrous, il ne peut pas
savoir si le poste est vraiment coupé (verrous à supprimer), ou s'il est
simplement en veille (verrous à conserver). De plus, quels sont les
serveurs de base de données qui gèrent bien les verrous ?

Postgresql surement.
http://docs.postgresqlfr.org/8.3/mvcc.html

Si le poste est déconnecté brutalement la connexion à la base de données
va automatiquement être coupée et la transaction et les verrous annulés.

je met un verrou sur l'entête dès qu'il y a la moindre modification à
venir sur une des lignes

Donc, verrouillage pessimiste. Le problème du verrouillage pessimiste
par en-têtes, c'est la cascade inverse. Si on va modifier une ligne de
facture, il faut, bien sûr, poser un verrou sur l'en-tête ; mais aussi
sur l'article, le client, l'établissement, etc. (pour cause d'intégrité
référentielle).
Si, par exemple lorsqu'un utilisateur veut faire une modification sur un
article très utilisé, dès que l'on aura plus de 5 ou 6 postes qui
facturent, la modif sera impossible, car toujours verrouillé par
quelqu'un d'autre.
Ou alors, il faut spécialiser les verrous, jusqu'au niveau des champs...
(bonjour l'usine à gaz).

Ca se fait il parait, mais faut vraiment en avoir l'utilité !
J'ai l'impression que tu mélange les problèmes de verrous au niveau base
de données et les verrous utilisateurs. Pour le côté base de données, je
ne vois pas le problème de poser un verrou très large vu que l'opération
va être instantanée et dans une transaction.

Enfin bref, j'essaye de ne pas mélanger les deux, cad que je n'utilise
pas les verrous BD pour verrouiller les utilisateurs mais des verrous
plus souples disons, avec timer éventuellement.
Pour les factures par ex, pas forcément besoin d'un verrou utilisateur
vu qu'on est obligé de copier toutes les données articles et clients,
peu importe s'ils changent pendant qu'on fait la saisie. C'est du cas
par cas quoi.

En fait, j'ai un problème, pour un logiciel que j'avais développé en
Paradox, et que je voudrais ré-écrire en Python. C'est un logiciel
spécifique, dans le domaine de la santé. Ce logiciel est utilisé
24h./24h., par un nombre de postes variant de 6 à 50 (simultanément).
Avec Paradox, le verrouillage (pessimiste) est réalisé automatiquement
au niveau de chaque ligne, ce qui réduit les interactions, car dès qu'un
utilisateur change de ligne, les verrous sont relâchés. Mais, cela veut
dire que l'on n'a qu'une seule ligne à la fois (quoique, si Paradox n'a
qu'une ligne en modif, il a les autres en visu seule, avec, en plus, un
rafraîchissement automatique, toutes les 6 secondes).

Ok, je comprend pourquoi tu mélange interface et bdd... Je raisonne
plutôt en terme d'appli web, donc sans lien direct entre l'interface et
le moteur.
Sur le wikipython par ex, quand un utilisateur modifie une page le
verrou tien un certain temps, faut faire des aperçus pour le conserver
plus longtemps.

J'ai bien quelques idées tordues, mais elles ne passent pas tous les
cas.

--
William Dodé - http://flibuste.net
Informaticien Indépendant

Michel Claveau - NoSpam SVP ; merci

07/08/2008 à 23:23

Re !

Postgresql surement.

PostGresql, comme la quasi totalité des SGBD SQL, ne gère pas le
verrouillage pessimiste.
Au mieux, ils gèrent le verrouillage optimiste ; mais, souvent, ils ne
gèrent même pas les verrous (charge à l'application de gérer elle-même
le verrouillage optimiste).
Dans ce dernier cas (fréquent), les choses se déroulent de la façon
suivante :
- l'application lit des données (et les mémorise)
- lors de la validation, l'application commence par re-faire une
requête avec un énorme where, reprenant toutes les valeurs de tous les
champs des données lues au début.
- si la requête est positive, la transaction est validée ; sinon, un
message avertit l'application, du genre "l'enregistrement a été modifié
par un autre utilisateur", ou "enregistrement déjà modifié".

Avantages : cela consomme très peu de ressources, les cas d'abandon ou
de coupure ne génèrent aucun problème.
Inconvénients : un utilisateur peut très bien voir son (dernier) travail
annulé, il faut travailler au niveau de l'enregistrement (de la ligne),
ou mieux, au niveau du champ.

Pour les factures par ex, pas forcément besoin d'un verrou utilisateur
vu qu'on est obligé de copier toutes les données articles et clients,
peu importe s'ils changent pendant qu'on fait la saisie. C'est du cas
par cas quoi.

Et si je prend un cas simple : une facture, avec une seule ligne (un
article, commandé 90 fois). Deux postes lisent simultanément cette ligne
(temps 0), pour y apporter une modification :
- le premier supprime la ligne, parce que le client n'est pas
solvable, et valide (temps 1)
- le second remplace le code article, pour une question de stock
(temps 2)

S'il n'y a pas de verrou, le travail effectué par le premier poste sera
annulé, sans aucun avertissement ni message.

A noter qu'un verrouillage pessimiste aura prévenu le second poste au
moment où il voudra modifier, qu'il y a un problème.

Et, avec un verrouillage optimiste, le second poste verra sa validation
rejetée. Avec un problème délicat : l'identification de l'enregistrement
à pister.

Sur le wikipython par ex, quand un utilisateur modifie une page le
verrou tien un certain temps, faut faire des aperçus pour le conserver
plus longtemps.

Un wiki a très peu de modifications, notamment simultanées (sur les
mêmes tables). En plus, la personne qui a modifié vérifie et peut
remodifier si besoin.
En gestion, avec les petits volumes dus à la taille des clients avec
lesquels je travaille, il y en a environ toutes les secondes ; avec des
utilisateurs qui ne peuvent pas re-vérifier ce qui a été fait.
Mais, avec les gros projets, on raisonne en centaines, ou milliers,
d'opérations par secondes.

A noter que, sur le web, le problème est souvent contourné par deux
faits :
- les internautes travaillent très rarement sur les mêmes dossiers /
comptes
- les informations sont souvent données à titre indicatif, et les
applications donnent les informations réelles plus tard, par e-mail, SMS
ou autre, après que la transaction soit validée. Ainsi, il m'arrive
assez souvent, chez un grossiste, de commander du matériel en stock, et
de recevoir, une heure après, un e-mail de confirmation... qui me donne
un délai de réappro.

Et encore, on ne parle que des cas simples. Avec les SGBD distribués,
déconnectés, etc. ça vire vite à une effroyable complexité.
D'ailleurs j'ai vu souvent des grosses applis, utilisant des SGBD connus
(SQl-server, Oracle, DB2, Firebird, etc.) QUI NE GÈRENT PAS CORRECTEMENT
LES VERROUS. Vu les niveaux de prix de ces logiciels (en millions
d'euros), je suis outré de tel manques. Mais, ça existe.

Bonne nuit.

MCI

Bref, ce n'est pas joie

Re !

Postgresql surement.

PostGresql, comme la quasi totalité des SGBD SQL, ne gère pas le
verrouillage pessimiste.
Au mieux, ils gèrent le verrouillage optimiste ; mais, souvent, ils ne
gèrent même pas les verrous (charge à l'application de gérer elle-même
le verrouillage optimiste).
Dans ce dernier cas (fréquent), les choses se déroulent de la façon
suivante :
- l'application lit des données (et les mémorise)
- lors de la validation, l'application commence par re-faire une
requête avec un énorme where, reprenant toutes les valeurs de tous les
champs des données lues au début.
- si la requête est positive, la transaction est validée ; sinon, un
message avertit l'application, du genre "l'enregistrement a été modifié
par un autre utilisateur", ou "enregistrement déjà modifié".

Avantages : cela consomme très peu de ressources, les cas d'abandon ou
de coupure ne génèrent aucun problème.
Inconvénients : un utilisateur peut très bien voir son (dernier) travail
annulé, il faut travailler au niveau de l'enregistrement (de la ligne),
ou mieux, au niveau du champ.

Pour les factures par ex, pas forcément besoin d'un verrou utilisateur
vu qu'on est obligé de copier toutes les données articles et clients,
peu importe s'ils changent pendant qu'on fait la saisie. C'est du cas
par cas quoi.

Et si je prend un cas simple : une facture, avec une seule ligne (un
article, commandé 90 fois). Deux postes lisent simultanément cette ligne
(temps 0), pour y apporter une modification :
- le premier supprime la ligne, parce que le client n'est pas
solvable, et valide (temps 1)
- le second remplace le code article, pour une question de stock
(temps 2)

S'il n'y a pas de verrou, le travail effectué par le premier poste sera
annulé, sans aucun avertissement ni message.

A noter qu'un verrouillage pessimiste aura prévenu le second poste au
moment où il voudra modifier, qu'il y a un problème.

Et, avec un verrouillage optimiste, le second poste verra sa validation
rejetée. Avec un problème délicat : l'identification de l'enregistrement
à pister.

Sur le wikipython par ex, quand un utilisateur modifie une page le
verrou tien un certain temps, faut faire des aperçus pour le conserver
plus longtemps.

Un wiki a très peu de modifications, notamment simultanées (sur les
mêmes tables). En plus, la personne qui a modifié vérifie et peut
remodifier si besoin.
En gestion, avec les petits volumes dus à la taille des clients avec
lesquels je travaille, il y en a environ toutes les secondes ; avec des
utilisateurs qui ne peuvent pas re-vérifier ce qui a été fait.
Mais, avec les gros projets, on raisonne en centaines, ou milliers,
d'opérations par secondes.

A noter que, sur le web, le problème est souvent contourné par deux
faits :
- les internautes travaillent très rarement sur les mêmes dossiers /
comptes
- les informations sont souvent données à titre indicatif, et les
applications donnent les informations réelles plus tard, par e-mail, SMS
ou autre, après que la transaction soit validée. Ainsi, il m'arrive
assez souvent, chez un grossiste, de commander du matériel en stock, et
de recevoir, une heure après, un e-mail de confirmation... qui me donne
un délai de réappro.

Et encore, on ne parle que des cas simples. Avec les SGBD distribués,
déconnectés, etc. ça vire vite à une effroyable complexité.
D'ailleurs j'ai vu souvent des grosses applis, utilisant des SGBD connus
(SQl-server, Oracle, DB2, Firebird, etc.) QUI NE GÈRENT PAS CORRECTEMENT
LES VERROUS. Vu les niveaux de prix de ces logiciels (en millions
d'euros), je suis outré de tel manques. Mais, ça existe.

Bonne nuit.

MCI

Bref, ce n'est pas joie

Vous avez filtré cet utilisateur ! Consultez son message

Re !

Postgresql surement.

PostGresql, comme la quasi totalité des SGBD SQL, ne gère pas le
verrouillage pessimiste.
Au mieux, ils gèrent le verrouillage optimiste ; mais, souvent, ils ne
gèrent même pas les verrous (charge à l'application de gérer elle-même
le verrouillage optimiste).
Dans ce dernier cas (fréquent), les choses se déroulent de la façon
suivante :
- l'application lit des données (et les mémorise)
- lors de la validation, l'application commence par re-faire une
requête avec un énorme where, reprenant toutes les valeurs de tous les
champs des données lues au début.
- si la requête est positive, la transaction est validée ; sinon, un
message avertit l'application, du genre "l'enregistrement a été modifié
par un autre utilisateur", ou "enregistrement déjà modifié".

Avantages : cela consomme très peu de ressources, les cas d'abandon ou
de coupure ne génèrent aucun problème.
Inconvénients : un utilisateur peut très bien voir son (dernier) travail
annulé, il faut travailler au niveau de l'enregistrement (de la ligne),
ou mieux, au niveau du champ.

Pour les factures par ex, pas forcément besoin d'un verrou utilisateur
vu qu'on est obligé de copier toutes les données articles et clients,
peu importe s'ils changent pendant qu'on fait la saisie. C'est du cas
par cas quoi.

Et si je prend un cas simple : une facture, avec une seule ligne (un
article, commandé 90 fois). Deux postes lisent simultanément cette ligne
(temps 0), pour y apporter une modification :
- le premier supprime la ligne, parce que le client n'est pas
solvable, et valide (temps 1)
- le second remplace le code article, pour une question de stock
(temps 2)

S'il n'y a pas de verrou, le travail effectué par le premier poste sera
annulé, sans aucun avertissement ni message.

A noter qu'un verrouillage pessimiste aura prévenu le second poste au
moment où il voudra modifier, qu'il y a un problème.

Et, avec un verrouillage optimiste, le second poste verra sa validation
rejetée. Avec un problème délicat : l'identification de l'enregistrement
à pister.

Sur le wikipython par ex, quand un utilisateur modifie une page le
verrou tien un certain temps, faut faire des aperçus pour le conserver
plus longtemps.

Un wiki a très peu de modifications, notamment simultanées (sur les
mêmes tables). En plus, la personne qui a modifié vérifie et peut
remodifier si besoin.
En gestion, avec les petits volumes dus à la taille des clients avec
lesquels je travaille, il y en a environ toutes les secondes ; avec des
utilisateurs qui ne peuvent pas re-vérifier ce qui a été fait.
Mais, avec les gros projets, on raisonne en centaines, ou milliers,
d'opérations par secondes.

A noter que, sur le web, le problème est souvent contourné par deux
faits :
- les internautes travaillent très rarement sur les mêmes dossiers /
comptes
- les informations sont souvent données à titre indicatif, et les
applications donnent les informations réelles plus tard, par e-mail, SMS
ou autre, après que la transaction soit validée. Ainsi, il m'arrive
assez souvent, chez un grossiste, de commander du matériel en stock, et
de recevoir, une heure après, un e-mail de confirmation... qui me donne
un délai de réappro.

Et encore, on ne parle que des cas simples. Avec les SGBD distribués,
déconnectés, etc. ça vire vite à une effroyable complexité.
D'ailleurs j'ai vu souvent des grosses applis, utilisant des SGBD connus
(SQl-server, Oracle, DB2, Firebird, etc.) QUI NE GÈRENT PAS CORRECTEMENT
LES VERROUS. Vu les niveaux de prix de ces logiciels (en millions
d'euros), je suis outré de tel manques. Mais, ça existe.

Bonne nuit.

MCI

Bref, ce n'est pas joie

William Dode

08/08/2008 à 11:21

On 07-08-2008, Michel Claveau - NoSpam SVP ; merci wrote:

Re !

Postgresql surement.

PostGresql, comme la quasi totalité des SGBD SQL, ne gère pas le
verrouillage pessimiste.

Parce que c'est un problème applicatif, le sgbd est chargé de la
cohérence des transactions, pas de l'interface utilisateur.
Sinon y a les "verrous informatifs" :
http://docs.postgresqlfr.org/8.3/explicit-locking.html

Et si je prend un cas simple : une facture, avec une seule ligne (un
article, commandé 90 fois). Deux postes lisent simultanément cette ligne
(temps 0), pour y apporter une modification :
- le premier supprime la ligne, parce que le client n'est pas
solvable, et valide (temps 1)
- le second remplace le code article, pour une question de stock
(temps 2)

S'il n'y a pas de verrou, le travail effectué par le premier poste sera
annulé, sans aucun avertissement ni message.

A noter qu'un verrouillage pessimiste aura prévenu le second poste au
moment où il voudra modifier, qu'il y a un problème.

Et, avec un verrouillage optimiste, le second poste verra sa validation
rejetée. Avec un problème délicat : l'identification de l'enregistrement
à pister.

Ce que tu voudrai c'est que deux personnes modifient la même facture en
même temps et voient en temps réel les modifications que l'un apporte
à une ligne ?

C'est clair que je ne gèrerai pas ce cas de figure avec une appli web.
Sinon, je ne vois pas de miracle, en appli web du moins, y a soit la
pose d'un verrou avec timer (comme le wiki), pour informer les autres,
soit comme tu l'as expliqué plus haut une vérif avant enregistrement (y
a t'il encore du stock à ce moment précis).
Au niveau du sgbd je pose les verrous _au moment de l'enregistrement_
uniquement. Et la j'ai tous les types verrous dont j'ai besoin pour que
l'entête soit cohérent avec les lignes, les stocks, la fiche article
etc.

Et encore, on ne parle que des cas simples. Avec les SGBD distribués,
déconnectés, etc. ça vire vite à une effroyable complexité.
D'ailleurs j'ai vu souvent des grosses applis, utilisant des SGBD connus
(SQl-server, Oracle, DB2, Firebird, etc.) QUI NE GÈRENT PAS CORRECTEMENT
LES VERROUS. Vu les niveaux de prix de ces logiciels (en millions
d'euros), je suis outré de tel manques. Mais, ça existe.

Tu parle au niveau applicatif ou au niveau sgbd ?
Ce que doit garantir un sgbd par ex c'est que justement s'il y a une
lacune dans l'application les données restent cohérentes. Ca c'est
gérable avec postgresql. Beaucoup moins avec mysql par ex.

C'est le dicton : EAFP "It is Easier to Ask for Forgiveness than to ask
for Permission." "Il est plus facile de demander pardon que de demander
la permission"

--
William Dodé - http://flibuste.net
Informaticien Indépendant

On 07-08-2008, Michel Claveau - NoSpam SVP ; merci wrote:

Re !

Postgresql surement.

PostGresql, comme la quasi totalité des SGBD SQL, ne gère pas le
verrouillage pessimiste.

Parce que c'est un problème applicatif, le sgbd est chargé de la
cohérence des transactions, pas de l'interface utilisateur.
Sinon y a les "verrous informatifs" :
http://docs.postgresqlfr.org/8.3/explicit-locking.html

Et si je prend un cas simple : une facture, avec une seule ligne (un
article, commandé 90 fois). Deux postes lisent simultanément cette ligne
(temps 0), pour y apporter une modification :
- le premier supprime la ligne, parce que le client n'est pas
solvable, et valide (temps 1)
- le second remplace le code article, pour une question de stock
(temps 2)

S'il n'y a pas de verrou, le travail effectué par le premier poste sera
annulé, sans aucun avertissement ni message.

A noter qu'un verrouillage pessimiste aura prévenu le second poste au
moment où il voudra modifier, qu'il y a un problème.

Et, avec un verrouillage optimiste, le second poste verra sa validation
rejetée. Avec un problème délicat : l'identification de l'enregistrement
à pister.

Ce que tu voudrai c'est que deux personnes modifient la même facture en
même temps et voient en temps réel les modifications que l'un apporte
à une ligne ?

C'est clair que je ne gèrerai pas ce cas de figure avec une appli web.
Sinon, je ne vois pas de miracle, en appli web du moins, y a soit la
pose d'un verrou avec timer (comme le wiki), pour informer les autres,
soit comme tu l'as expliqué plus haut une vérif avant enregistrement (y
a t'il encore du stock à ce moment précis).
Au niveau du sgbd je pose les verrous _au moment de l'enregistrement_
uniquement. Et la j'ai tous les types verrous dont j'ai besoin pour que
l'entête soit cohérent avec les lignes, les stocks, la fiche article
etc.

Et encore, on ne parle que des cas simples. Avec les SGBD distribués,
déconnectés, etc. ça vire vite à une effroyable complexité.
D'ailleurs j'ai vu souvent des grosses applis, utilisant des SGBD connus
(SQl-server, Oracle, DB2, Firebird, etc.) QUI NE GÈRENT PAS CORRECTEMENT
LES VERROUS. Vu les niveaux de prix de ces logiciels (en millions
d'euros), je suis outré de tel manques. Mais, ça existe.

Tu parle au niveau applicatif ou au niveau sgbd ?
Ce que doit garantir un sgbd par ex c'est que justement s'il y a une
lacune dans l'application les données restent cohérentes. Ca c'est
gérable avec postgresql. Beaucoup moins avec mysql par ex.

C'est le dicton : EAFP "It is Easier to Ask for Forgiveness than to ask
for Permission." "Il est plus facile de demander pardon que de demander
la permission"

--
William Dodé - http://flibuste.net
Informaticien Indépendant

Vous avez filtré cet utilisateur ! Consultez son message

On 07-08-2008, Michel Claveau - NoSpam SVP ; merci wrote:

Re !

Postgresql surement.

PostGresql, comme la quasi totalité des SGBD SQL, ne gère pas le
verrouillage pessimiste.

Parce que c'est un problème applicatif, le sgbd est chargé de la
cohérence des transactions, pas de l'interface utilisateur.
Sinon y a les "verrous informatifs" :
http://docs.postgresqlfr.org/8.3/explicit-locking.html

Et si je prend un cas simple : une facture, avec une seule ligne (un
article, commandé 90 fois). Deux postes lisent simultanément cette ligne
(temps 0), pour y apporter une modification :
- le premier supprime la ligne, parce que le client n'est pas
solvable, et valide (temps 1)
- le second remplace le code article, pour une question de stock
(temps 2)

S'il n'y a pas de verrou, le travail effectué par le premier poste sera
annulé, sans aucun avertissement ni message.

A noter qu'un verrouillage pessimiste aura prévenu le second poste au
moment où il voudra modifier, qu'il y a un problème.

Et, avec un verrouillage optimiste, le second poste verra sa validation
rejetée. Avec un problème délicat : l'identification de l'enregistrement
à pister.

Ce que tu voudrai c'est que deux personnes modifient la même facture en
même temps et voient en temps réel les modifications que l'un apporte
à une ligne ?

C'est clair que je ne gèrerai pas ce cas de figure avec une appli web.
Sinon, je ne vois pas de miracle, en appli web du moins, y a soit la
pose d'un verrou avec timer (comme le wiki), pour informer les autres,
soit comme tu l'as expliqué plus haut une vérif avant enregistrement (y
a t'il encore du stock à ce moment précis).
Au niveau du sgbd je pose les verrous _au moment de l'enregistrement_
uniquement. Et la j'ai tous les types verrous dont j'ai besoin pour que
l'entête soit cohérent avec les lignes, les stocks, la fiche article
etc.

Et encore, on ne parle que des cas simples. Avec les SGBD distribués,
déconnectés, etc. ça vire vite à une effroyable complexité.
D'ailleurs j'ai vu souvent des grosses applis, utilisant des SGBD connus
(SQl-server, Oracle, DB2, Firebird, etc.) QUI NE GÈRENT PAS CORRECTEMENT
LES VERROUS. Vu les niveaux de prix de ces logiciels (en millions
d'euros), je suis outré de tel manques. Mais, ça existe.

Tu parle au niveau applicatif ou au niveau sgbd ?
Ce que doit garantir un sgbd par ex c'est que justement s'il y a une
lacune dans l'application les données restent cohérentes. Ca c'est
gérable avec postgresql. Beaucoup moins avec mysql par ex.

C'est le dicton : EAFP "It is Easier to Ask for Forgiveness than to ask
for Permission." "Il est plus facile de demander pardon que de demander
la permission"

--
William Dodé - http://flibuste.net
Informaticien Indépendant

chris

18/08/2008 à 11:34

Michel Claveau - NoSpam SVP ; merci a écrit :

Re !

Et encore, on ne parle que des cas simples. Avec les SGBD distribués,
déconnectés, etc. ça vire vite à une effroyable complexité.
D'ailleurs j'ai vu souvent des grosses applis, utilisant des SGBD connus
(SQl-server, Oracle, DB2, Firebird, etc.) QUI NE GÈRENT PAS CORRECTEMENT
LES VERROUS. Vu les niveaux de prix de ces logiciels (en millions
d'euros), je suis outré de tel manques. Mais, ça existe.

Connaissant bien le problème vu qu'il s'agit de ma partie (ERP/PGI) , le
problème est très complexe quelque que soit le système ou la base de
données
et c'est pour cette raison que le problème doit être géré au niveau
logiciel ET base de données sinon on perd l'ouverture de la base ce qui
est classique même chez les grands ERP/PGI

Il est nécessaire de respecter 2 choses :

* Une modification effectue la pose d'un verrou BDD ET LOGICIEL ainsi
si 2 personnes veulent modifier le même client une seule doit pouvoir le
faire mais la 2eme doit etre au courant

* les tables maitres doivent être decouper en 2 parties voire plus
exemple la table produit ou client une partie accessible que par
traitement et une partie accessible par les utilisateurs

Ainsi si un utilisateur est en train de modifier un produit (le nom la
désignation le prix etc ...) il ne doit pas bloquer les mises à jour
effectué par traitement sinon tout les process attendrait la fin de la
modif (cas réel d'il ya qq années : je me mets en modif sur un client et
je repond au tel vais faire pipi ... )

Mettre en place des modifications limités dans le temps possible mais
pas toujours exemple : la télévente je reste en modif sur une commande
pendant le temps de la communication et cela peut durer longtemps

bref sans les utilisateurs l'informatique serait simple mais simple ...

A+
chris

William Dode

18/08/2008 à 13:51

On 18-08-2008, chris wrote:

Michel Claveau - NoSpam SVP ; merci a écrit :
Re !

Et encore, on ne parle que des cas simples. Avec les SGBD distribués,
déconnectés, etc. ça vire vite à une effroyable complexité.
D'ailleurs j'ai vu souvent des grosses applis, utilisant des SGBD connus
(SQl-server, Oracle, DB2, Firebird, etc.) QUI NE GÈRENT PAS CORRECTEMENT
LES VERROUS. Vu les niveaux de prix de ces logiciels (en millions
d'euros), je suis outré de tel manques. Mais, ça existe.

Connaissant bien le problème vu qu'il s'agit de ma partie (ERP/PGI) , le
problème est très complexe quelque que soit le système ou la base de
données
et c'est pour cette raison que le problème doit être géré au niveau
logiciel ET base de données sinon on perd l'ouverture de la base ce qui
est classique même chez les grands ERP/PGI

Il est nécessaire de respecter 2 choses :

* Une modification effectue la pose d'un verrou BDD ET LOGICIEL ainsi
si 2 personnes veulent modifier le même client une seule doit pouvoir le
faire mais la 2eme doit etre au courant

Concrètement tu met quoi comme verrou sur la BDD (et sur quelle BDD)
? Un verrou qui tient la perte de connexion (pour une appli web) ?

--
William Dodé - http://flibuste.net
Informaticien Indépendant

Méta-MCI (MVP)

19/08/2008 à 01:16

Bonsoir !

Finalement, pas de solution miracle.

En pratique, on (je) constate que c'est rarement bien géré. Car, la
plupart du temps, soit les développeurs ne font rien, soit ils n'ont
même pas conscience qu'il peut y avoir un problème.

Parce que, gérer les verrous au niveau du SGBD, ça pose plein de
problèmes, selon les SGBD ; et, les travailler au niveau des applis,
c'est encore pire (genre : comment traiter les verrous posés par un
(autre) poste qui est en veille ?)

D'autant plus que les verrous peuvent être exponentiels. Du genre : pour
modifier un client, on verrouille son enregistrement, puis, en cascade,
toutes ses factures, tous ses BL, tous ses paiements, et, donc, toutes
les lignes des factures, BL, encaissements. Sans compter les
sous-comptes, les adresses de livraison multiples, les tarifs, les
fiches techniques, les devis, les courriers, etc. etc.

Je réfléchis à des moyens tordus ; mais, pour l'instant, je bute
toujours qq part.

@-salutations
--
Michel Claveau

Méta-MCI (MVP)

19/08/2008 à 01:19

Bonsoir !

il s'agit de ma partie (ERP/PGI)

Dommage que tu habites à l'étranger (en dehors de l'Ardèche), car on
aurait pu se faire quelques discussions intéressantes.

@+
--
Michel Claveau

William Dode

19/08/2008 à 08:57

On 18-08-2008, Méta-MCI wrote:

Bonsoir !

Finalement, pas de solution miracle.

En pratique, on (je) constate que c'est rarement bien géré. Car, la
plupart du temps, soit les développeurs ne font rien, soit ils n'ont
même pas conscience qu'il peut y avoir un problème.

Parce que, gérer les verrous au niveau du SGBD, ça pose plein de
problèmes, selon les SGBD ; et, les travailler au niveau des applis,
c'est encore pire (genre : comment traiter les verrous posés par un
(autre) poste qui est en veille ?)

Sur le sgbd il n'y aura jamais de solutions toutes faites, chaque cas
applicatif est trop particulier. amha il ne faut pas regarder les
verrous des sbgd, ce n'est pas qu'ils ne les gèrent pas correctement
c'est qu'ils ne servent pas du tout à ça. Par contre en utilisant les
procédures stockées et les triggers il y a moyen de forcer l'application
a être cohérente, si c'est ça qui te semble manquer ?
Je t'invite à poser ta question sur la liste postgresqlfr... Le
4 octobre y a une rencontre à Toulouse http://www.pgday.fr

Pour le poste en veille, à part un timer je vois pas...

--
William Dodé - http://flibuste.net
Informaticien Indépendant

Comment faites-vous (bases de données)

10 réponses

Veuillez sélectionner un problème