Toutes les applications et sites qui utilisent des données d'une base HFSQL client/serveur, reposent sur une connexion permanente entre l'application, ou le site, et le moteur HFSQL client/serveur. Cette connexion repose sur le protocole TCP/IP, et l'utilisation de sockets.

Pas d'exception pour confirmer la règle, qu'il s'agisse :

• d'une application WINDEV sous Windows 32 ou 64 bits,
• d'un site WEBDEV,
• d'une application mobile sous iOS ou Android compilée avec WINDEV Mobile,
• d'un moteur HFSQL client/serveur installé sur un réseau local, distant, ou dans un CLOUD (PCSCLOUD, ...),

c'est toujours une connexion TCP qui servira à l'envoi des requêtes au moteur HFSQL client/serveur, à la récupération des données...

Le but de ce billet est de détailler comment sont faites les connexions, puis surtout les déconnexions. En effet comme toujours, lorsque l'on connaît le principe de fonctionnement, il devient plus simple de déterminer les solutions à mettre en place, quelque soit le but à atteindre !

L'ouverture d'une connexion se fait :

• lors d'un appel explicite de la fonction HOuvreConnexion,
• ou implicitement dès qu'il sera nécessaire d'interroger le serveur, car toutes les fonctions HFSQL (H*), ouvrent si besoin la connexion associée aux tables. C'est valable pour les connexions décrites dans l'analyse, mais également par programmation, ou paramétrées lors du déploiement de l'application.

Dans les deux cas le centre de contrôle HFSQL (CCHF) permet de visualiser les connexions ouvertes par les applications, via le volet "Connexions". C'est un autre sujet, mais soulignons qu'un même processus peut instancier plusieurs clients HFSQL et donc ouvrir plusieurs connexions, grâce aux contextes HFSQL indépendants (disponible également pour les classes).

Voici maintenant les différents cas possibles qui vont terminer les connexions :

1. L'application n'a plus besoin des données du serveur et poursuit son exécution dans une phase n'utilisant pas de donnée. Elle peut terminer ses connexions par un appel de la fonction HFermeConnexion. Elle libère ainsi sur le serveur les ressources nécessaires aux différentes connexions ouvertes.
2. L'application est terminée par son utilisateur par son option standard de fermeturen sans faire appel à HFermeConnexion. Toutes les connexions ouvertes par le processus sont automatiquement fermées. En effet dans ce cas l'arrêt du processus déclenche le déchargement des modules du framework, dont le client HFSQL fait partie. Le client HFSQL informe le serveur de l'arrêt du processus et, le moteur HFSQL peut donc supprimer les connexions.
3. L'application est terminée par un arrêt du processus (fin de tâche sur le processus). Dans ce cas le client HFSQL n'est pas déchargé, il ne peut donc envoyer au moteur HFSQL client/serveur la demande de fermeture des connexions en cours. Dans ce cas, c'est une fonctionnalité du système d'exploitation qui prend le relais. En effet, il gère automatiquement l'envoi d'un paquet réseau spécifique (RST) pour les connexions TCP de l'application. Le moteur HFSQL client/serveur gère la récupération de ces paquets, ainsi il peut mettre fin aux connexions même s'il n'a pas été notifié de façon standard par l'application.
   
   Dans ces 3 cas, le moteur HFSQL client/serveur est notifié de l'arrêt de l'application et toutes les connexions sont immédiatement supprimées.
   
   
4. L'application n'est pas terminée, mais la connexion réseau est perdue. Pour le moteur HFSQL client/serveur la connexion est donc toujours présente, puisque ni l'application, ni le système client n'a pu le notifier (cas 1 2 3) [ 26/12/2017 voir mise à jour en fin de billet ]. Dans ce cas la connexion va persister sur le serveur, jusqu'à :
   
   - la reconnexion automatique ou programmée de l'application qui était connectée, si la coupure de connexion n'a été que temporaire, et qu'il n'y avait aucune donnée bloquée (Cf. Limites de la fonction HReconnecte),
   
   - un envoi d'information du moteur HFSQL client/serveur à cette connexion, par exemple un message, dans ce cas le serveur pourra détecter la connexion rompu et la supprimer,
   
   - la réception d'une notification du système d'exploitation serveur sur le fait que la connexion TCP n'existe plus. En effet, les systèmes serveurs notifient régulièrement les processus qui communiquent via TCP/IP, dont le moteur HFSQL client/serveur, afin de leur signaler les éventuelles connexions qui ne sont plus valides. Dans ce cas le temps nécessaire pour que le moteur HFSQL client/serveur supprime la connexion est très variable, la fréquence de notification par le système étant réglable sur les serveurs (généralement aux alentours de deux heures).

En premier, pas d'inquiétude en cas d'une simple micro-coupure sur la connexion. En effet, puisque le moteur HFSQL client/serveur garde les connexions, les applications vont poursuivre leur exécution dès que la connexion sera restaurée (tant que le processus n'est pas arrêté). Voici les liens utiles en complément sur ce thème :

• Reconnexion automatique au serveur HFSQL,
• pour personnaliser les actions en cas de déconnexion : HsurErreur,
• pour effectuer une reconnexion : HReconnecte.

Ensuite dans le cas général la gestion des connexions ne nécessite aucune programmation spécifique, puisque même si la déconnexion n'est pas explicitement faite par l'application, le système permettra au moteur HFSQL de terminer une connexion inutile à plus ou moins court terme.

Enfin, on peut noter l'importance du fait que le moteur HFSQL client/serveur peut de lui-même supprimer une connexion perdue, si la communication vers l'application client liée à la connexion n'est plus joignable. En effet, si l'application qui a perdu la connexion vers le serveur a bloqué des enregistrements de la base de données, par défaut les données restent bloquées tant que le système serveur n'a pas notifié le moteur HFSQL client/serveur. Si une transaction était en cours, elle reste également active. Suivant le domaine d'activité, un déblocage plus rapide peut être souhaité. On peut donc l'obtenir en jouant sur le fait que le moteur HFSQL client/serveur supprime les connexions inexistantes, s'il tente l'envoi d'un message vers l'une de ces connexions. Pour forcer une communication du moteur HFSQL client/serveur vers les processus clients, dans le cas général toutes les communications sont à l'initiative des applications clientes, on peut utiliser la fonction HEnvoieMessageVersClient.

L'utilisation de cette solution avec HEnvoieMessageVersClient doit être prévue dans l'application, sous peine d'afficher des messages sur les postes de tous les utilisateurs de l'application, y compris ceux qui n'ont jamais été déconnectés ! La fonction HSurAppelServeur doit être appelée par les applications afin de personnaliser la gestion de l'affichage des messages, justement pour ne rien afficher ! Exemple de procédure (bien pratique) de réponse à HSurAppelServeur :

On note au passage que cette méthode peut permettre de commander à distance des actions aux applications ! Dans certains cas et du moment que toutes les applications partagent leur données via un même serveur HFSQL client/serveur, cela remplace avantageusement une solution du dialogue par socket ou messages Windows. D'autant plus que la structure HClient permet de gérer finement l'envoi des messages. Un exemple d'utilisation de HEnvoieMessageVersClient a été proposé dans la LST 90 p30 : WD Notification.

A partir de sa version 23 HFSQL Client/Serveur permet de définir un time-out ou plus précisément un time-to-live (TTL). Le serveur peut donc se charger de libérer les connexions, sans avoir recours à la méthode décrite ci-dessus.