Discussion :

[AsmCode]

Bonjour, je fais une application client avec une bd mysql. Jusqu'ici j'étais avec 4.1 mais pour une question pratique j'envisage de passer à la 5.0 pour les stored procedures. L'application est un genre d'agenda électronique.

Mais comme la bd est partagé entre les clients, donc n'importe qui peut ajouter/modifier/supprimer des rendez-vous, etc. Je m'étais fait un genre de système pour barrer une journée d'un agenda pendant que l'utilisateur la modifie pour ne pas que les autres puissent changer les données. Imaginez quand un usager veut créer un rendez-vous et avant qu'il ne sauvegarde le rendez-vous un autre usager a déjà enregistrer un rendez-vous qui rentre en conflit avec les heures choisis de l'autre.

Et si je fais dans visual basic un if then else pour savoir si c'est toujours libre, pendant que vb fait son if then else, ça n'empêche pas un autre usager d'envoyer une requête SQL au serveur pour modifier les données, donc cette solution n'est pas valide, même si les chances sont faibles.

Alors je me suis dit qu'avec les stored procedures je pourrais me passer de barrer la journée et faire un if then else, puisque (à moins que je me trompe) quand MySQL exécute la stored procedure, rien ne peut se passer pendant ce temps, puisque MySQL n'exécute qu'une seule requête à la fois.

Mais j'aurais besoin d'une confirmation

Car il sajit d'un agenda électronique dont les rendez-vous sont importants et ne doivent pas être écrasés par erreur si plusieurs usagers essaie de rentrer des rendez-vous dans les même heures ou tenter de modifier des données qui ont déjà été modifiés pendant leur dernier 'refresh'

Merci

[berceker united]

Tu peux bloquer une table SQL Pendant que tu fais ta soupe. Ceci évite les risques de conflit ou d'ecrasement de l'information. Mais attention, il faut bien lire la doc pour jouer avec les histoires de lock de table.

[AsmCode]

Tu peux bloquer une table SQL Pendant que tu fais ta soupe. Ceci évite les risques de conflit ou d'ecrasement de l'information. Mais attention, il faut bien lire la doc pour jouer avec les histoires de lock de table.

Salut, mais je veux éviter de bloquer la table justement, sinon tout les agendas seront bloqués ce qui n'a pas de sens. Seul 1 agenda pour 1 date doit être bloqué.

Ma structure est la suivante:

Table: Agenda
Agenda_Id
Agenda_Name

Table Caldate
Cal_Id
Cal_AgendaId
Cal_Date

et dans une autre table je mettais un enregistrement comme quoi le Cal_Id (disons 1) était bloqué par l'usagé xyz sur tel pc.

De cette façon les autres peuvent modifier leurs agendas, seul l'agenda pour la date xyz est bloqué pendant que l'usager fait ses modifs.

Mais par cette façon, un truc m'embête c'est que si l'usagé sort de l'application anormalement (plantage du pc, connexion réseau rompue, plantage du exe, etc) L'info de blocage reste dans la bd.

Ça ne débloque que si l'usager quitte le formulaire avec le bouton quitter ou quand il démarre l'application.

Pour 5.0 je pensais mettre un triggers, mais je ne sais pas comment ça pourrait fonctionner. Je crois que les triggers sont faits seulement pour se déclencher à aux changements sur une table.

Alors ce que j'avais fait pour ça avec 4.1 c'est que quand l'usagé est en train de faire des modifs, il met à jour l'heure du lock aux 30 sec et les autres instances de l'application qui tournent(y compris lui-même en fait) fait un update à toute les minutes pour enlever les lock qui sont expiré de plus de 30 sec.

Ça fonctionne #1 mais je me demande si il n'y aurait pas une façon plus simple, plus élégante. J'utilise un timer, mais même dans une application client-serveur il y a quand même un timer qui vérifie l'arrivé de messages donc ça revient au même.

[Adjanakis]

Bonjour,

Si le storage Engine est InnoDB, cette page pourrait être intéressante :
http://dev.mysql.com/doc/refman/5.0/...ing-reads.html

[AsmCode]

Bonjour,

Si le storage Engine est InnoDB, cette page pourrait être intéressante :
http://dev.mysql.com/doc/refman/5.0/...ing-reads.html

Salut, en fait j'utilise l'autre type, mais je pourrais toujours migrer. Mais ce que je me demandais c'est si j'utilises une stored procedure, quand mysql exécute une stored procedure est-ce qu'il est multi-tâche ? peut-il exécuter la même stored procedure (ou une autre requête) pendant qu'il est en train d'en exécuter une ?

Je crois que InnoDB pourrait me convenir, car je n'aurais qu'à faire un Select for update, les enregistrements seraient barrés. Et pour ce qui est des ajouts, l'usagé qui enregistrera ses ajouts en deuxième se verra recevoir un message comme quoi les ajouts qu'il tente de faire entre en conflit avec des enregistrements existants, si conflit il y a.

Qu'en pensez-vous ? Sur ce, je me demandais si il y aurait moyen de déterminer quels conflits il y a, peut-être une stored procedure avec des variables Out ?

Mais je me demande ce qui est mieux, que l'usagé se rende compte qu'il ne peut enregistrer ses nouveaux trucs, car ça entre en conflit, car un autre usagé l'a devancé entretemps ou bien qu'il sache immédiatement qu'il ne peut pas, car la journée de l'agenda x est barré et qu'il doit attendre que l'usagé z sorte ou finisse ses trucs ?

Je pourrais toujours faire un lock par les heures au lieu de par les journées, mais c'est que un usager ne sait pas toujours d'avance ce qu'il va faire, un client apelle, il veut un rendez-vous on lui demande à quelle heure il souhaite son rendez-vous, ou on lui propose une heure libre et on lui demande si ça lui convient, mais les changements ne sont pas nécessairement uniquement au niveau des heures, on pourrait avoir a ajouter des notes sur cette journée, y déplacer un rendez-vous, etc. C'est assez imprévisible.

[Antoun]

La solution est clairement les transactions InnoDB, qui te permettent un lock ligne par ligne.

MySQL est effectivement capable d'exécuter plusieurs procédures concurrentes à la fois, d'où l'importance de mettre tes procs dans des transactions.

Tu as intérêt à lire de très prêt la doc et/ou un bon tutoriel (ou un bon bouquin ), et à tester toutes les hypothèses. Arriver à un bon niveau d'isolation sans bloquer tout le système est un sacré boulot !