Comment depuis un TService, géreriez-vous un accès à un serveur Firebird alors que le réseau est peu fiable ou quand le serveur est en maintenance, sans savoir quand ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Accès Firebird et réseau peu fiable !
Comment depuis un TService, géreriez-vous un accès à un serveur Firebird alors que le réseau est peu fiable ou quand le serveur est en maintenance, sans savoir quand ?
Un peu vague comme demande.
Peu importe que cela soit un TService ou FireBird, un réseau peu fiable implique un gestion d'un cache local et des tentatives d'envoie de données, en fait, cela revient plus à faire une application en mode déconnecté (Briefcase dans le vieux jargon Delphi)
Si l'on ajoute FireBird, comment gérer les transactions non abouties, comme répéter les instructions sans les dupliquer, comment gérer de la conciliation si les données existantes sont différentes ne permettant plus les mises à jour ...
La connexion directe à FireBird est-elle sage ? Pourquoi ne pas partir sur un mode déconnecté, un client REST utilisant quand il en a la possibilité un serveur REST (lui ayant un bon accès à la DB)
Ne pas hésiter à travailler en asynchrone, le server REST renvoie un numéro de transaction, le client au lieu d'attendre la réponse du traitement, pourra à l'inverse vérifier les transactions validées et mettre à jour son cache en conséquence, un choix à faire entre un grand nombre de petite requête ou à l'inverse quelques grosses requêtes, dans un réseau peu fiable, mieux vaut se limiter du peu.
La maintenance, c'est un autre problème, on connait tous des serveurs backup la nuit, il faut juste prévoir un code robuste, c'est un sujet différent, une anomalie ponctuelle à gérer, ce n'est pas comme avoir un réseau de piètre qualité en permanence.
Est-ce une application nomade ?
J'ai connu cela il y a 15 ans (le projet en ayant déjà 10 à l'époque), 2h d'électricité par jour, alors la saisie était faite rapidement, envoie des données à un centralisateur local, lui même ayant un centralisateur régional, national et le siège.
Tous les ID AutoInc étaient complété par des GUID pour assurer la conciliation de 2500 bases locales vers la base centralisée.
Tout ça en DBase.
Aujourd'hui, il y a la 4G au pire la 3G, à l'époque c'était du 56K !
Alors que signifie un "réseau peu fiable" de nos jours ?
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
Je suppose que tes postes clients servent à collecter de la data
Si tu es dans un réseau privé (c'est à dire pas obligé de passer par Internet) entre le serveur et les autres postes, tu peux aussi avoir un service (ou plusieurs) sur le serveur qui vient relever les données des postes clients.
J'avais fait ça pour un client : les postes bord de ligne ramassent les données de production en temps réel, les horodatent, et les enregistrent en local. Puis plusieurs threads sur le serveur viennent relever les données de façon régulière (toutes les minutes). Si le serveur n'est pas joignable sur le réseau pendant quelques minutes, c'est pas gênant, les postes peuvent continuer à fonctionner pendant plusieurs heures, c'est la capacité de stockage de ces postes qui sera exploitée.
Comme le volume de données n'est pas énorme, lorsque le serveur est de nouveau disponible, la récupération de centaines d'enregistrements (au pire quelques milliers) ne prend que quelques secondes
Dans ce cas, tu fais, en quelque sorte, du "egde computing"
Tout cela dépend aussi de la structure des bases de données et des données métier, échanges unidirectionnels, ou bi-directionnels, nombre de tables impactées, etc...
Mon idée était de détecter une perte de connexion pour mettre en pause les traitements et de les relancer dés que le serveur est de nouveau opérationnel, du coup, je cherche un moyen fiable, car je n’ai pas la maîtrise du réseau ni à quel moment certains peuvent intervenir dessus, ni sur l’architecture logiciel retenu, hélas !
Si je comprends bien le but est d'interrompre un traitement local, sans rapport direct avec la base de données, parce que son résultat ne pourra de toute façon pas être mis à jour, c'est bien ça ?
Si oui et que tu travailles avec FireDac, tu peux ping-er le serveur à intervalles réguliers.
Tu devrais gérer une table contenant les taches à faire, ainsi tu auras un suivi, à toi de voir la granularité, une tache n'est-elle qu'une transaction ou un traitement plus long qui sera découpé (un import par exemple, capacité de reprendre à partir d'un point précis)Envoyé par der§en
Et si tu perds la connexion, il suffit de retenter plus tard si tu as prévu un scheduler qui dépile les taches.
En passant par des tables temporaires pour travailler puis finaliser qu'à l'étape ultime dans les tables métiers, cela facilite aussi la reprise à chaud. à un niveau architecture, on il faut définir un Plan de continuité d'activité, savoir si tu peux avoir un spare pour préparer certaines taches avant de retrouver le serveur principal ...
C'est le cas classique d'un serveur coupé la nuit pour maintenance ou le week-end, il faut toujours prévoir un code robuste à l'erreur, qu'elle soit planifiée ou imprévue.
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
Le choix originel a été fait d’utiliser UIB pour accéder à Firebird !
Merci pour vos suggestions…
UIB, Zeos ou Firedac le problème sera le même :
- Tenter d'établir la connexion au serveur : si pas de réponse ne pas lancer les traitements maintenant
- Si connexion OK, tu lances les traitements, mais tu devra catcher correctement les exceptions, car de ce je comprends, la connexion peut se terminer de façon inopinée.
Ta gestion d'erreur doit être irréprochable
Dans tous les cas, il faudra passer par des transactions pour garantir la consistance de la base en face.
Quand on a pas de ping de la base, on envoie généralement une requête à blanc pour vérifier que la connexion est bien toujours valide, par exemple :
Si la requête échoue (même pas la peine de tester le retour, juste l'exception), cela veut dire que ta connexion n'est plus valide.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Il faut déconnecter tes objets proprement coté service et essayer de rétablir une nouvelle connexion
Merci Sergio_is_back, je ne connaissait pas cette méthode, je vais la tester
Je vais explorer vos suggestions, merci à tous.
J’ai trouvé une solution très simple en utilisant cette classe : TUIBServerInfo
Répondre avec citation
Partager