Discussion :

[aristeas]

Bonjour,

J'aimerais avoir vos conseils sur l'organisation que doit avoir un programme Java pour l'utilisation d'une base SQL liée au serveur qui sert à exécuter les requêtes (actions) et transmettre les résultats aux clients.

Car j'ai une crainte sur le fait que le client affiche l'interface avant même que le serveur réponde (genre si le serveur prend 6 secondes pour répondre).

Dois je "bloquer" l'affichage, ou bien rafraichir lorsque la réponse arrive ?
Mais alors comment s'y prendre ?
Comment savoir l'interface à rafraichir (utilisation des abstract ?) ?

Si quelqu'un à un début de réponse, je suis preneur.

Merci d'avance.

[Laurent.B]

Bonjour,

Ta question est très imprécise car tu ne précises pas la façon dont ton application est connectée à la base et dans quel environnement cela se passe...

Quoi qu'il en soit, tant que l'action de l'utilisateur est faite de manière classique, c'est à dire sans passer par un thread démarré explicitement, il n'y a pas de raison que l'utilisateur obtienne une réponse prématurée...

Pour l'histoire de l'abstract, à moins que je n'ai rien compris à ce que tu cherches à faire, je dirais que c'est hors sujet.

[aristeas]

lu,

Désolé, je vais réessayer autrement :

Avec java swing (avec une JFrame, ...), j'ai un thread client et un thread serveur qui se connect en TCP avec les sockets.

Mon souci réside dans l'organisation que je dois appliquer pour que les réponses reçu du serveur soit bien pris en compte sur l'écran du client. Sachant que la requete au serveur est envoyé au moment ou l'interface cliente est en construction et donc en cours d'affichage.
De plus pendant ce temps le client peut recevoir d'autres messages du serveur, pour d'autres interfaces.

Donc actuellement j'applique le rafraichissement, toute les secondes avec un "timer" dédié, des interfaces client à l'écran, qui le nécessite, afin de remettre les données à jour (Risque d'occuper des ressources pour rien).

Néanmoins j'aurai espéré faire autrement ; genre attribuer un "serial" au message client-serveur qui correspondrait au "serial" des interfaces à mettre à jour, si elles sont affichées bien sur. Résultat la mise a jour des données est effectué que si c'est nécessaire.
Mais cela me semble compliqué et pas très viable.

Une autre solution serait de "jouer" avec les ports de connexions au serveur. Mais la complexité de gestion est tout aussi ardu et peu viable.


Hélas je ne vois pas d'autres façon "simple" de m'y prendre.

@+

[Laurent.B]

Avec java swing (avec une JFrame, ...), j'ai un thread clibent et un thread serveur qui se connect en TCP avec les sockets.

Bien et la connexion JDBC à la base, c'est la partie serveur qui s'en charge, c'est bien ça ?

la requete au serveur est envoyé au moment ou l'interface cliente est en construction et donc en cours d'affichage.

Si c'est du constructeur que tu parles, il est plus propre de lancer la requête après.

De plus pendant ce temps le client peut recevoir d'autres messages du serveur, pour d'autres interfaces.

Ok, donc ça veut dire que tu as des traitements asynchrones ?

Donc actuellement j'applique le rafraichissement, toute les secondes avec un "timer" dédié, des interfaces client à l'écran, qui le nécessite, afin de remettre les données à jour (Risque d'occuper des ressources pour rien).

Si les données côté serveur ne sont pas susceptibles de changer de façon externe, il n'y a pas d'intérêt à avoir un thread pour rafraichir l'IHM, dans le cas contraire tu n'as pas trop le choix mais tout dépend de l'importance d'avoir un rafraichissement continu et fréquent ou pas.

Néanmoins j'aurai espéré faire autrement ; genre attribuer un "serial" au message client-serveur qui correspondrait au "serial" des interfaces à mettre à jour, si elles sont affichées bien sur. Résultat la mise a jour des données est effectué que si c'est nécessaire.
Mais cela me semble compliqué et pas très viable.

Pourquoi ?

Une autre solution serait de "jouer" avec les ports de connexions au serveur. Mais la complexité de gestion est tout aussi ardu et peu viable.

Euh oui, je pense même que ça ne changerait pas grand chose au problème...

Bon, je dirais que tes explications ne sont toujours pas suffisantes car il y a mille et une façon de procéder en fonction du contexte.

Etudie la notion de Listener, si ce n'est déjà fait, car à mon avis ça te sera bien utile.