05-10-2012, 09:59 AM
Pas obligatoirement. Il me semble que MySQL (entre autres, ca doit surement être le cas des autres SGBD) possède une fonctionnalité permettant de verrouiller une table (ou une ligne d'un table?). Le principe est alors que si le script A verrouille la ligne, et que B essaie d'y accéder pendant ce temps, alors B récupère soit une exception, soit B est mis en attente jusqu'à ce que A déverrouille la ligne. Sur MyISAM, cela serait le principe à appliquer il me semble. Sur InnoDB, il est possible de créer des COMMIT, autrement dit, créer des "groupes" de commandes SQL. La propriété de ces groupes est que si une commande du groupe n'aboutit pas, alors tout le groupe est annulé (ca, c'est ce que j'ai compris), et on retrouve l'état que la BDD avait avant l'exécution de la première requète du groupe (donc, admetton que le commit ait un UPDATE et 3 INSERT, si le COMMIT plante au 2e INSERT, alors le UPDATE et le 1er INSERT seront annulés, comme s'ils n'avaient jamais été faits).
Il doit donc être possible de s'en servir dans ton cas de scripts conflictuels.
Il existe une dernière solution, un peu barbare, qui consisterait à créer une table à part, dans laquelle chaque script inscrit les verrouillages qu'il demande. Par exemple, le script A veut modifier l'objet d'Id N dans la table T, alors il vérifie d'abord que, dans la table de verrouillage, il n'y a pas l'objet N de la table T; et s'il n'y est pas, le script enregistre, dans la table de verrouillage, que l'objet N de la table T est verrouillé par le script. Une fois le script terminé, il supprime l'enregistrement de cet objet dans la table de verrouillage.
C'est lourd, mais c'est une solution.
Pour ma part, je pense que si tu as le risque d'un conflit entre deux scripts, alors tu dois probablement pouvoir repenser légèrement ton concept pour éviter ce problème. Ne connaissant pas le concept que tu as en tête, je me trompes peut-etre (ce n'est peut être pas possible de modifier ce concept, tout comme cela peut être possible).
(Arf, je devrais essayer d'être plus synthétique dans mes réponses >w>)
Il doit donc être possible de s'en servir dans ton cas de scripts conflictuels.
Il existe une dernière solution, un peu barbare, qui consisterait à créer une table à part, dans laquelle chaque script inscrit les verrouillages qu'il demande. Par exemple, le script A veut modifier l'objet d'Id N dans la table T, alors il vérifie d'abord que, dans la table de verrouillage, il n'y a pas l'objet N de la table T; et s'il n'y est pas, le script enregistre, dans la table de verrouillage, que l'objet N de la table T est verrouillé par le script. Une fois le script terminé, il supprime l'enregistrement de cet objet dans la table de verrouillage.
C'est lourd, mais c'est une solution.
Pour ma part, je pense que si tu as le risque d'un conflit entre deux scripts, alors tu dois probablement pouvoir repenser légèrement ton concept pour éviter ce problème. Ne connaissant pas le concept que tu as en tête, je me trompes peut-etre (ce n'est peut être pas possible de modifier ce concept, tout comme cela peut être possible).
(Arf, je devrais essayer d'être plus synthétique dans mes réponses >w>)