Bonjour,
dans TODO.txt, je ne vois rien de plus à propos des accès concurrents
que :
"un système de timestamp pour repérer les collisions sur les articles
sortis pour edition"
Qu'y a-t'il déjà dans SPIP, que je n'aurais pas encore décelé, pour
répondre à cette problématique, et qu'y a-t'il de prévu pour bientôt ?
Merci.
Nicolas.
Salut Nicolas,
Il faudrait revoir la discussion sur le sujet qui eut lieu il y a quelques
temps ; personnellement le système de timestamp ne me satisfait pas du tout 
a+
Antoine.
Nicolas Hoizey wrote:
Salut Antoine,
Il faudrait revoir la discussion sur le sujet qui eut lieu il y a
quelques temps
Je viens de relire quelques messages, ce n'était pas très constructif
finalement, peu de choses concrètes en sont ressorties.
personnellement le système de timestamp ne me satisfait pas du tout
Il faut mixer des locks et un timestamp d'après moi, mais je ne suis
pas expert en accès concurrentiels ...
Personne n'a jamais eu de problèmes d'écrasement de données à cause de
ce gros manque dans SPIP ???
Nicolas.
Hello,
> personnellement le système de timestamp ne me satisfait pas du tout
Il faut mixer des locks et un timestamp d'après moi, mais je ne suis
pas expert en accès concurrentiels ...
Moi non plus mais le problème n'est pas vraiment d'obtenir un truc
infaillible, juste un système utilisable.
Personne n'a jamais eu de problèmes d'écrasement de données à cause de
ce gros manque dans SPIP ???
Si, mais comme aucun des deux outils possibles n'était disponible,
ça n'avance pas grand'chose sur le diagnostic. En général, quand tu
écris un article à plusieurs, tu communiques avec les autres auteurs
pour éviter ce genre de mésaventure ; c'est artisanal, comme les
"attention je modifie l'espace privé" sur la présente liste. Un
système de locks permettrait simplement d'avoir une interface pour
faire la même chose de façon commode, sans remplir les forums
d'annonces diverses et variées. Le timestamp, à l'inverse, t'informe
juste qu'il y a eu une modif, mais trop tard, et tu ne connais pas non
plus la teneur de la modif.
a+
Antoine.
Messieurs,
Je me suis abonné à cette liste de dev sur le conseil de Nicolas suite à
une question que j'avais sur ce problème de lock des articles.
Il faut mixer des locks et un timestamp d'après moi, mais je ne suis
pas expert en accès concurrentiels ...
Je ne sais pas si je peux me donner le titre "d'expert" en la matière,
mais je vais faire un petit résumé de ce que doit être un verrou d'accès
concurentiel dans le cadre d'un outil comme spip.
Personne n'a jamais eu de problèmes d'écrasement de données à cause de
ce gros manque dans SPIP ???
Si, nécessairement, ce n'est qu'une question de probabilité...
On raisonne bien sûr sur le même article.
On dispose d'une table de trois colonnes :
lock_table : id_article, login, timelocked
PK=(id_article, login)
Quand quelqu'un clique sur "modifier cet article" ou chaque création
d'article, on essaie d'insérer la ligne :
insert into lock_table (l'identifiant courant, mon login, sysdate());
Si l'insert réussit, j'ai pris le verrou.
S'il ne réussit pas les cas suivants sont à envisager :
- erreur de base de donnée, tout le monde et dans les choux, exit.
- quelqu'un d'autre a déjà le verrou.
Le problème se pose alors de savoir si quelqu'un bosse *vraiment* sur
l'article ou si il a abandonné ses modifs.
Je met LOCK_TO en define de mettons 30 minutes.
On a deux moyens de le gérer :
1) tenter directement un update de la ligne avec la clause where :
update lock_table set login=mon_login where id_article=l'identifiant AND
timelocked < sysdate()-LOCK_TO)
Si l'update est OK, on est parti en time out, et j'ai pris le verrou.
Sinon, quelqu'un bosse dessus (ou la connexion base est plantée).
2) Faire un select count(1) from lock_table where id_article=xxx and
timelocked < sysdate()-LOCK_TO
Si j'ai un rang il y a une modification "active" de l'article.
Si j'ai plus d'un rang, erreur grave.
Si je n'ai aucun rang (time out de plus d'une demi heure), je *propose*
de prendre le verrou mais ce n'est pas obligatoire. Dans ce cas je
m'appelle avec un troisième paramètrede forçage de verrou et je fais
l'update de la méthode 1 sans clause where sur le timelocked.
Le retour peut être alors :
update OK (c'est bon, j'ai le verrou)
update ok (base plantée parce que cas impossible, mais à sortir dans un
log d'erreur).
Ma préférence va à la deuxième solution même si elle oblige le codage
d'un écran supplémentaire.
Quoi qu'il en soit, au bout d'un moment, j'ai mon verrou et je peux
tripoter l'article.
Bien entendu, tout ceci est mis au sein d'une fonction PHP genre
get_lock() qui renvoie un code d'erreur "kivabien" (verrou acquis, ok,
ou ko en cours de modif) et qui a entrée les deux paramètres identifiant
article et login et un troisième facultatif dans le cas de la solution
numéro 2 pour forcer ou non la prise de verrou.
Bien maintenant, la perte du verrou.
Quand on clique sur "valider" on ne revient pas au même écran avec
posibilité de re-valider de nouveau. Donc ça va nous simplifier la
tâche, parce que toute validation implique perte de verrou (quitte à le
reprendre deux secondes après en cliquant de nouveau sur modifier).
Cette fonction release_lock() admet en paramètre les mêmes que
get_lock() à savoir l'id de l'article et le login.
On fait simplement un delete from lock_table where id_article=xxx and
login=yyy
Si le delete réussit, OK, on avait encore le verrou et les modifs
peuvent être commitées en base.
Si le delete plante, quelqu'un a pris le verrou entre temps, il ne FAUT
PAS prendre en compte les modifs (et voir si on augmente ou non le temps
LOCK_TO) (ou alors on a perdu la connexion à la base et de toutes façons
au revoir)
On peut ensuite voir à faire un système de merge des modifs, mais là ça
devient compliqué.
Sur ce, je pense que je vous ai donné quasiment les lignes de code à
écrire mais je suis tout à fait dispo pour aider au codage de ces deux
fonctions, relire le code produit, etc...
a++; JG
(PS : tu vois Nico, deux chtites fonctions de rien du tout et c'est
torché).
Hello,
Je me suis abonné à cette liste de dev sur le conseil de Nicolas
suite à une question que j'avais sur ce problème de lock des
articles.
J'avoue, c'est ma très grande faute ... 
1) tenter directement un update de la ligne avec la clause where :
update lock_table set login=mon_login where id_article=l'identifiant
AND timelocked < sysdate()-LOCK_TO)
Si l'update est OK, on est parti en time out, et j'ai pris le
verrou. Sinon, quelqu'un bosse dessus (ou la connexion base est
plantée).
Ca plante aussi la première fois qu'on prend un verrou sur cet
article, donc à remplacer par un insert lors de la création.
2) Faire un select count(1) from lock_table where id_article=xxx and
timelocked < sysdate()-LOCK_TO
[...]
Ma préférence va à la deuxième solution même si elle oblige le
codage d'un écran supplémentaire.
Quel écran ?
Bien maintenant, la perte du verrou.
[...]
Si le delete plante, quelqu'un a pris le verrou entre temps, il ne
FAUT PAS prendre en compte les modifs
Ou, mais plus compliqué, s'il n'y a plus de verrou (c'est à dire que
l'autre qui l'avait pris l'a relaché), proposer un merge manuel en
montrant la version modifiée entre temps.
(PS : tu vois Nico, deux chtites fonctions de rien du tout et c'est
torché).
Mouaih ...
Nicolas.
Re,
J'avoue, c'est ma très grande faute ...
Il l'a dit...
Ca plante aussi la première fois qu'on prend un verrou sur cet
article, donc à remplacer par un insert lors de la création.
Non, car on est ici dans le cas où l'insert a échoué. J'ai bien écrit
qu'on tente l'insert d'abord, et si l'insert échoue alors on tente
l'update (car insert qui réussit implique verrou acquis ce qui est aussi
le cas de la création).
> Ma préférence va à la deuxième solution même si elle oblige le
> codage d'un écran supplémentaire.
Quel écran ?
Celui où tu proposes de faire du "manual override" est-ce que vous
voulez forcer le verrou ou pas.
Ou, mais plus compliqué, s'il n'y a plus de verrou (c'est à dire que
l'autre qui l'avait pris l'a relaché), proposer un merge manuel en
montrant la version modifiée entre temps.
Vi, vi, c'est bien ce que je disais en dessous. Mais tu sais proposer un
diff en PHP sous windows toi ? Moi je sais pas. Déjà que parser le
résultat d'un diff sous unix et l'afficher avec les parties communes en
texte, et les parties à merger en combo... ça serait pas de la tarte.
Donc faisons simple dans un premier temps.
> (PS : tu vois Nico, deux chtites fonctions de rien du tout et c'est
> torché).
Mouaih ...
Pfff, il est d'une mauvaise foi ;-))
a++
JG
Salut,
Merci pour ces conseils techniques 
En fait c'est plus le modus
operandi en lui-même qui est sujet à discussion. En effet un
verrou automatique d'une durée t a pour grand inconvénient de
masquer les différentes modalités de modification d'un article,
d'un auteur à l'autre, d'une modification à l'autre :
- on peut très bien modifier un article pendant deux minutes
(corriger une faute d'orthographe). Là, ça marche car l'appui
sur valider libère le verrou.
- on peut cliquer sur modifier et puis oublier la fenêtre dans
un coin, ou fermer le navigateur, ou faire "back". Le texte sera
indûment signalé comme verrouillé à une autre personne, pendant
toute la durée t. Si cela se produit souvent, il y a fort à
parier que le système de verrou ne sera plus pris au sérieux,
et systématiquement ignoré (comme les alarmes de voiture qui
n'arrêtent pas de se déclencher).
- on peut modifier un article pendant plusieurs heures (ça
existe, on l'a expérimenté sur uzine). Certains auteurs sont
spécialistes de ça : ils sont partis pour faire deux trois ptites
modifs, et au final ils réécrivent la moitié du texte (je ne
cite personne :-)). Dans ce cas le verrou aura été libéré
automatiquement, et éventuellement pris par quelqu'un d'autre.
Encore plusieurs cas :
-> le deuxième auteur ne modifie rien, le premier auteur aura
un message lui signalant qu'il n'y a plus le verrou pour valider
les modifs, alors que ce message est inutile. C'est corrigeable
en comparant un hash des données lors de la sortie du texte,
et lors de la tentative de validation des modifs.
-> le deuxième auteur modifie alors que l'article est encore
verrouillé de son côté. C'est notifié au premier quand il
valide, mais il faut qu'il reprenne ses modifs à la main pour
fusionner avec celle du deuxième auteur.
-> le deuxième auteur modifie avant le premier, mais après
l'expiration de son propre verrou. L'utilisation d'un hash
permet éventuellement de notifier le premier auteur lorsqu'il
essaie à son tour de valider les modifs, mais là encore il
est bon pour tout reprendre et fusionner à la main (et il a
intérêt à avoir copié/collé ou sauvé ses modifs qqepart, hem).
- on peut enfin modifier un article à partir d'une copie locale
et n'appuyer sur modifier qu'au moment où l'on veut valider ce
qui aura été réalisé sous l'éditeur de texte (ou Word pour les
débutants), donc un verrou automatique n'est ici d'aucune utilité
contre les collisions.
C'est pour ça que je préférerais un verrou manuel, par lequel
un auteur peut indiquer pour combien de temps il veut verrouiller
l'article. C'est moins "automatique" mais ça permet aux auteurs
de gérer plus intelligemment le travail de groupe (qu'il faut,
de toute façon, gérer d'une façon ou d'une autre). De plus ça
évite les surprises liées au fonctionnement bizarre d'un machin
automatique qui ne se réveille pas quand il faut : quand on n'est
pas pro en informatique, il n'y a je pense rien de plus déroutant
que ce genre de mécanisme rigide et incompréhensible au premier
abord.
De plus, avec un verrou manuel, on peut ajouter une zone optionnelle
de message pour indiquer aux autres quelle est la nature des modifs
à venir. On peut même faire (pas moi, je ne connais pas Javascript
un petit timer dans la page de modification qui affiche un message
d'alerte quand le lock expire, avec un formulaire pour le prolonger
d'une durée au choix.
Amicalement
Antoine.
Bonjour,
parier que le système de verrou ne sera plus pris au sérieux,
et systématiquement ignoré (comme les alarmes de voiture qui
n'arrêtent pas de se déclencher).
Ceci est un autre sujet : si des utilisateurs sont suffisement
indélicats pour vérouiller inutilement des documents, c'est leur
problème, non celui de la gestion des locks.
- on peut modifier un article pendant plusieurs heures (ça
existe, on l'a expérimenté sur uzine). Certains auteurs sont
C'est là ausi une question de comportement. Cf la méthode d'en dessous
(pomme-c pomme-v en deux secondes).
- on peut enfin modifier un article à partir d'une copie locale
et n'appuyer sur modifier qu'au moment où l'on veut valider ce
qui aura été réalisé sous l'éditeur de texte (ou Word pour les
débutants), donc un verrou automatique n'est ici d'aucune utilité
contre les collisions.
Je ne comprends pas la conclusion : le cheminement dans les écrans est
le même quelle que soit la méthode de rédaction. Il n'y a pas de
différence entre une personne qui clique sur "modifier cet article",
ajoute une ligne puis valider et celui qui chqnge tout le contenu par
pomme-c pomme-v au lieu de ne modifier que deux lignes.
C'est pour ça que je préférerais un verrou manuel, par lequel
un auteur peut indiquer pour combien de temps il veut verrouiller
l'article.
Dans ce cas, tout ce que j'ai dit hier est toujours valable, mais la
colonne timelocked est gérée différement. Il suffit de passer le temps
prévu de travail en paramètre d'entrée et stocker dans la table non pas
l'heure courante mais l'heure de levée du verrour (et de remplacer dans
mon algo toutes les comparaisons d'heure contenant LOCK_TO avec l'heure
courante tout court).
C'est moins "automatique" mais ça permet aux auteurs
de gérer plus intelligemment le travail de groupe
Oui et non. Il y a fort à paier que les mêmes zigotos qui prendraient un
document pour finalement ne pas le modifier vont indiquer qu'ils ont
l'intention de bosser dessus pendant des heures... pour finalement ne
pas le modifier.
automatique qui ne se réveille pas quand il faut : quand on n'est
pas pro en informatique, il n'y a je pense rien de plus déroutant
que ce genre de mécanisme rigide et incompréhensible au premier
abord.
Et j'llais dire "il suffit de le mettre dans la doc" mais j'ai oblié que
personne le la lit, donc pourquoi pas.
Mais comment expliquer simplement à un "non pro informatique" ce qu'est
un verrou et combien de temps il doit entrer ? Donc ce genre de
mécanismes "obscurs" a l'avantage non négligeable d'être transparent.
De plus, avec un verrou manuel, on peut ajouter une zone optionnelle
de message pour indiquer aux autres quelle est la nature des modifs
Non, on peut le faire dans TOUS les cas.
On peut même faire (pas moi, je ne connais pas Javascript
un petit timer dans la page de modification qui affiche un message
d'alerte quand le lock expire, avec un formulaire pour le prolonger
d'une durée au choix.
Oui, ça c'est une idée, mais qui est applicable dans le cas d'un verrou
automatique aussi...
En résumé je ne suis absolument pas convaincu que le "tout manuel" soit
une solution plus "user friendly" (au contraire même, expliquer ce
qu'est un verrour à certains sera "drôle")et il FAUT TOUJOURS de toutes
façons prévoir un time out de sécurité. Ce sera peut être deux heures,
mais il en FAUT un (pour prévoir le cas du gars qui commence à bosser,
puis son PC plante et finalement il se barre et on a rien eu le temps de
voir côté serveur).
Sur ce, je laisse aux gardiens du temple la décision de la méthode, mais
je ne continuerai pas à utiliser ce logiciel sans ce type de sécurité
qui me paraissent indipensable dans un projet de développement
**collectif** donc hautement concurentiel.
a++; JG
Hello,
on peut enfin modifier un article à partir d'une copie locale et
n'appuyer sur modifier qu'au moment où l'on veut valider ce qui aura
été réalisé sous l'éditeur de texte
C'est une pratique à interdire dans SPIP, puisqu'il est alors
impossible de gérer le fait que la copie locale n'est pas à jour par
rapport à des modifs faites en ligne.
Il faut sensibiliser les utilisateurs pour leur dire que c'est une
méthode utilisable uniquement AVANT CREATION d'un article, mais pas
ensuite.
Nicolas.
> on peut enfin modifier un article à partir d'une copie locale et
> n'appuyer sur modifier qu'au moment où l'on veut valider ce qui aura
> été réalisé sous l'éditeur de texte
C'est une pratique à interdire dans SPIP, puisqu'il est alors
impossible de gérer le fait que la copie locale n'est pas à jour par
rapport à des modifs faites en ligne.
Heu ? je crois que je n'ai pas compris la bidouille qui était faite.
JG
on peut enfin modifier un article à partir d'une copie locale
C'est une pratique à interdire dans SPIP
Heu ? je crois que je n'ai pas compris la bidouille qui était faite.
Monsieur X fait une copie de l'article sur son Mac à 13h, et le
modifie.
Monsieur Y fait une modif en ligne à 14h.
Monsieur X modifie en ligne en faisant pomme-C/pomme-V depuis son
éditeur local.
Les modifs de monsieur Y sont perdues, et aucun lock ne peut y changer
quoi que ce soit.
Nicolas.
Nicolas Hoizey wrote:
Monsieur X fait une copie de l'article sur son Mac à 13h, et le
modifie.Monsieur Y fait une modif en ligne à 14h.
Monsieur X modifie en ligne en faisant pomme-C/pomme-V depuis son
éditeur local.Les modifs de monsieur Y sont perdues, et aucun lock ne peut y changer
quoi que ce soit.
Si, un lock manuel à 13h par Monsieur X.
....
> Les modifs de monsieur Y sont perdues, et aucun lock ne peut y changer
> quoi que ce soit.Si, un lock manuel à 13h par Monsieur X.
Faux dans les deux affirmations.
Ce qui peut empêcher l'écrasement, c'est la présence d'un lock tout
court et l'algo que j'ai donné gère le cas : en effet, en essayant de
modifier, onne trouve pas de verrou, ça veut donc dire que quelqu'un a
modifié le document depuis DONC interdiction de le toucher.
Donc SI, les modifs de monsieur Y peuvent être protégées des tripotages
de monseiru X, et NON, le fait que le lock de monsieur X soit manuel ne
changera RIEN (qu'il soit manuel ou autmatique et dans tous les cas avec
time out, ça marchera).
Je ne comprends pas pourquoi vous vous mélangez tous les crayons à ce
point, c'est pourtant simple avec ces deux principes de base :
1) je ne peux pas obtenir le document si je ne pose pas un verrou
dessus.
2) je ne peux pas rendre le document si je ne suis pas propriétaire d'un
verrou posé dessus.
J'ai géré toutes les sources de Paribas Asset Management Technologies
avec ces deux principes pendant un an et demi (et le produit était là
avant moi, et le sera encore après) et on n'a jamais eu d'écrasement de
version. Et il n'y avait pas intérêt, le code gére pour plusieurs
millions de francs par jour de transactions boursières.
Qu'après on ergote sur la durée du time out et la possibilité ou non de
choisir cette durée ne change RIEN, mais alors RIEN DU TOUT sur les
principes et les protections apportées.
Sur ce, je vais télécharger le code de spip sur ma machine, écrire le
code de protection tel que je l'ai donné, le déployer sur notre site et
le rendre public et vous en ferez ce que vous voudrez, si j'avais
directement fait ça ce serait déjà fini.
a++
John
Bonjour,
Dans l'animation d'un site, il est important que l'administrateur principal soit prévenu des messages postés au pied des articles ou des brèves.
Quelle position avez-vous prise pour la version en cours 1.3 ?
Dans la 1.2.1 seul l'auteur de l'article est prévenu.
Serait-il possible que dans "Configurer" on ait qq chose du type :
Envoi des forums aux administrateurs du site
"Lorsqu'un visiteur du site poste un message dans les forums associés à un article ou une brève, le texte de ce message peut être envoyé par mail aux administrateurs du site.
Souhaitez-vous utiliser cette option ?"
* Faire suivre les messages des forums à l'adresse mail : ..........
* Ne pas faire suivre les messages des forums
A +
J.Chatignoux
@ John Gallet (john.gallet@wanadoo.fr) :
En résumé je ne suis absolument pas convaincu que le "tout manuel" soit
une solution plus "user friendly" (au contraire même, expliquer ce
qu'est un verrour à certains sera "drôle")et il FAUT TOUJOURS de toutes
façons prévoir un time out de sécurité. Ce sera peut être deux heures,
J'abonde, et je crois qu'il vaut mieux qu'il soit invisible. Les cas que
présente Antoine sont vraiment limite... pour bosser à plusieurs il faut
apprendre à éviter de garder la fenêtre de modif ouverte pendant deux
plombes, ou alors on le signale par un message interne.
Sur ce, je vais télécharger le code de spip sur ma machine, écrire le code
de protection tel que je l'ai donné, le déployer sur notre site et le
rendre public et vous en ferez ce que vous voudrez, si j'avais directement
fait ça ce serait déjà fini.
Excellent !
-- Fil
Bonjour,
J'ai géré toutes les sources de Paribas Asset Management Technologies
avec ces deux principes pendant un an et demi (et le produit était là
avant moi, et le sera encore après) et on n'a jamais eu d'écrasement de
version. Et il n'y avait pas intérêt, le code gére pour plusieurs
millions de francs par jour de transactions boursières.
Vous n'avez pas compris où est le problème. Il n'est pas d'avoir une
protection à toute épreuve, au prix d'une discipline importante au
sein d'une équipe soudée de contributeurs. Il est d'offrir un mécanisme
simple, souple et compréhensible à des utilisateurs qui n'ont pas de
culture informatique, ne sont pas habitués à travailler ensemble (ni
même en groupe de manière générale), et n'ont probablement pas envie
de se plier à un mécanisme autoritaire. Il n'y a pas d'administrateur
système ou de chef de projet intégré à SPIP pour mettre au pas les
utilisateurs et leur dire doctement ce qui est interdit, autorisé,
et préconisé. La solution adoptée doit se soumettre à cet état de fait
et non l'inverse. Et le terme "solution" n'a pas trait à l'implémentation
technique mais aux caractéristiques fonctionnelles du système. S'il
s'agissait de programmer une bête exclusion mutuelle, il n'y aurait
aucune raison d'en discuter pendant des heures.
Amicalement
Antoine.
Re,
Vous n'avez pas compris où est le problème.
Vous avez répondu à côté de la plaque.
La solution adoptée doit se soumettre à cet état de fait
En quoi celle que j'ai proposé n'y répond pas ?
Tous les cas sont gérés, même ceux correspondant aux comportements les
plus tordus. Vous voulez pouvoir régler le temps pendant lequel ou
verrouille par saisie utilisateur ? Oui, c'est possible. Un gars fait
n'importe quoi en local sans avoir pris un verrou ? Non, il ne foutra
pas le souk dans le projet (ah oui, parce que ça *moi* je ne l'autorise
pas c'est ça ?)
En ce qui me concerne, EOT, je suis venu sur cette liste avec
l'intention de vous aider à donner à votre logiciel une fonctionnalité
sans laquelle il n'a pas de raison d'être dans le cadre de développement
collaboratif (ou alors c'est chacun dans son coin sur son article et je
n'appelle pas ça du collaboratif) j'en repars comme j'étais arrivé, je
le code dès que j'ai un moment, je vous donne ces sources et vous en
ferez ce que vous voudrez.
Je tiens néanmoins à préciser que je suis de plus en plus ahuris par les
délires "pseudo-libertaires" qui traînent partout : on laisse faire tout
et surtout n'importe quoi à n'importe qui et on risque de perdre des
heures de boulot tout ça pour ne pas froisser le petit égo du luser
moyen. A vouloir contenter tout le monde, c'est la production en elle
même qu'on met en péril.
Sur ce je vous salue bien bas et je vais finir la vaisselle du repas
d'hier soir.
JG