Méthode de rafraichissement d'un thread

Bonjour,

Je me demandais comment mettre en place un thread pour rafraîchir automatiquement un bloc.

Je m'explique, j'ai une application multi-poste.
Imaginons un Poste 1, il met a jour les données du bloc.

J'aimerais que sur le poste 2, quasi-instantané, j'ai le rafraîchissement du bloc.

Pour obtenir ce rafraîchissement, je pensais :
-Mettre un thread de cadencement rapide 1s.
-Mettre un écouteur.
-->Suite à l'écouteur provoquer le rafraîchissement du bloc.

l'écouteur serait une requête SQL!

Ce qui me gêne c'est le thread de cadencement de 1s, qui risque de perturbé et ralentir grandement l'application et le serveur BDD. Car ça obligerait a exécuter une requête SQL toutes les secondes sur tous les postes.

Je cherche une méthode ou pratique pour ce genre de problème.
Comment y remédier?

Merci

Juste une idée au passage, tu pourrais peut être utiliser RMI en ayant un serveur sur lequel les 2 clients se connectent et mettent à jour les données qui sont répercutés sur tous les clients?

J'ai compris ton idée.
Mais dans mon cas, chaque postes devra être client et serveur à la fois sans config préalable.

Le seul serveur en commun est une connexion à une base de donnée.

la bdd se trouve ou?

la bdd se situe:
-soit sur un serveur externe
-soit sur un poste client.

J'ai représenté ci joint le schéma type que je pensais appliquer :

Pas forcément la meilleure idée d'architecture.

Dans ce genre de cas, afin de pouvoir gérer les interactions avec la base de données de façon unique, et de pouvoir pousser une notification directe en cas de modification aux autres clients, on préfère intercaler un serveur proposant des services de type SOAP/REST/RMI ou autres entre la base de données et les clients. De plus cela de permet d'éviter d'embarquer les users / mots de passe de la base au niveau de client, et d'éviter d'ouvrir la base en accès direct à tout le monde.

Plus de tracer de façon propre qui a fait quoi.


L'archi que je proposerait est de créer donc des services SOAP ou REST selon ta préférence pour chaque action disponible dans ton application (au sens fonctionnel, pas au sens base de données). Chaque service ira ensuite faire la ou les actions nécessaire en base une fois l'appel effectué par le client.

Ensuite, pour notifier les clients qu'une nouvelle version des données a été effectuée, il est préférable de publier cette information en un endroit ou elle sera disponible pour chaque client. Pour celà, un topic JMS est une solution plutôt accordée.

Suite à chaque create/update/delete correctement en base, le serveur d'application balance un message sur le topic JMS, topic sur lequel écoutent l'intégralité des clients.
A chaque message posté sur le topic, les client vont être notifiés du message et directement exécuter le code que tu auras préparé à cet effet.


Schéma d'archi:

Merci pour ta réponse Sinok ;)

La BDD n'est pas forcément ouverte à tous le monde car elle peut être associé a une adresse IP fixe.

L'application que je développe est une solution pour gérer sa comptabilité.
Le client a le choix sur le serveur BDD, soit interne soit externe.
Si externe c'est un paramétrage de l'accès à la BDD manuel.

Si j'ai bien compris, la meilleure solution serait de mettre un fichier intermédiaire.
-Ce fichier serait écouté par un thread de cadencement (attentif au changement).
-Dans le cas de modification de la BDD on le notifie dans le fichier.

Le problème de passer par les services SOAP/REST/RMI impose de passer par un serveur intercaler. Ce qui impose les clients a avoir accès a un fichier en commun.

Si il y a une autre méthode que de passer par un fichier intermédiaire, je préfère.
Car dans le cas de mon application, l’intérêt d'avoir accès a la BDD en externe a surtout l'avantage de pouvoir travailler sur une autre machine.
Il n'y aura généralement pas plus de 2 clients connectés en simultaner sur la même BDD.