Discussion :

[dbilem]

Bonjour,
lorsqu'une base de données est modifiée par un client via une requête quelconque, comment les autres clients connectés sur la base peuvent-ils être informés en temps réel des modifications effectuées sur celle-ci?

Je n'ai rien trouvé dans la documentation...

J'utilise MySQL V5.1 et l'API C.

De manière générale, connaitriez-vous des articles intéressants sur les accès concurrents? et surtout leur mise en pratique au niveau d'un logiciel en C/C++.

Merci.

[Sivrît]

Bonjour,
lorsqu'une base de données est modifiée par un client via une requête quelconque, comment les autres clients connectés sur la base peuvent-ils être informés en temps réel des modifications effectuées sur celle-ci?

Je n'ai rien trouvé dans la documentation...

Normal, y'a pas

Le plus simple serait peut-être d'utiliser un serveur de messages pour que les clients puissent se notifier les uns les autres des changements qu'ils font. Sinon jouer sur des trigger pour garder des traces dans changements que les clients pourront consulter ? Ou alors il faudrait que les trigger puissent envoyer des notifications mais à ma connaissance ça n'existe pas encore dans MySQL donc ça supposerait de créer un plugin (peut-être déjà fait par quelqu'un ?).

Sinon peut-être en faisant passer les client par un mysql proxy et en lui faisant envoyer des notifications. Ca devrait pouvoir se bricoler.

De manière générale, connaitriez-vous des articles intéressants sur les accès concurrents? et surtout leur mise en pratique au niveau d'un logiciel en C/C++.

Je ne pense pas que ce soit spécifique au C/C++, c'est plutôt une affaire de SQL. Je pense que les mots clefs dans la doc seront "niveaux d'isolation" et "verrous". Peut-être aussi regarder ce que font les mappings objet-relationnel avec leurs verrouillage dit optimiste.

[dbilem]

Merci Sivrit pour ta promptitude,
bon en effet je crois qu'une table traçant "grossièrement" les changements effectués sur la base par un client, alimentée par des TRIGGERs sur les tables importantes, pourrait être une bonne idée... et à ma portée. Les autres solutions sont hors de mon champ de compétence.
Maintenant pour cette solution il appartient aux différents clients de s'enquérir périodiquement des modifications pertinentes sur la base via un SELECT sur cette table. Cela semble viable pour des modifications peu fréquentes, peu volumineuses, un nombre de clients peu élevé... cette solution n'étant certainement pas la plus élégante puisqu'elle tend à émettre sur le réseau des requêtes inutiles, mais bon à défaut...

merci encore

si quelqu'un a une idée ...

dbilem