Discussion :

[jorrie]

Bonjours, je voulais savoir si il etait possible de connaittre l'etat d'une connexion en temps reel.

J'ai thread qui verifierais l'etat de ma connexion et si par exemple le service sql server s'arrete mon logiciel se place en mode deconnecter.

Mais la seule solution que j'ai trouver est de placer un executescalar dans mon thread et de retourner un false si le scalar plante.

Existe un moyen moins gourment que lancer executescalar sans cesse ? dois je forcement atteindre la bdd pour savoir si j'ai plus de liaison avec elle?

J'ai bien penser à verifier le service directement mais mon logiciel tourne aussi bien sur mysql, oracle et sql server

[Bluedeep]

Bonjour

Je ne vois pas trop bien l'interêt de connaitre l'état d'une connexion en temps réel dans la mesure où la durée de vie d'une connexion est justement censée être la plus courte possible (on instancie la connexion, on prépare la commande, on ouvre la connexion, on exécute la commande, on ferme et on désalloue la connexion).

[jorrie]

tu rouvre pas une connexion a chaque requete ?

ce que je desire c'est de pouvoir savoir en temps si ma connexion est toujours viable.
Car si j'arrete le service sql server, je m'apercoie de la perte de ma connexion seulement lors du plantage et je trouve un peu tard l'avertissement

[Bluedeep]

tu rouvre pas une connexion a chaque requete ?

C'est la pratique normale de programmation. Les "pools" n'ont pas été inventés que pour le ball trap (EDIT : d'ailleurs c'est PULL dans le cas du ball trap - voulu tenter un jeu de mot et c'est raté ).

ce que je desire c'est de pouvoir savoir en temps si ma connexion est toujours viable.

Comme je te l'ai dit, ça n'a pas de justification.

Car si j'arrete le service sql server, je m'apercoie de la perte de ma connexion seulement lors du plantage et je trouve un peu tard l'avertissement

En dehors du fait qu'un arrêt du service correspond pas à une situatiion normale en production, et entraine normalement une remontée d'alerte vers le cockpit de supervision ou ce qui en tient lieu, tu gère vraisemblablement mal la durée de vie de ta connexion.

[jorrie]

en gros c'est a moi d'intercepter l'erreur si je perd ma connexion ?

[Bluedeep]

en gros c'est a moi d'intercepter l'erreur si je perd ma connexion ?

Je ne sais pas d'où te vient cette obsession sur les "pertes de connexion". Une connexion a (sauf programmation vraiment mal fichue ou commande longue) une durée de vie très courte; donc, on l'ouvre, on exécute la commande, on ferme.

Il peut y avoir un problème entre les deux, ou sur l'exécution mais en général le problème va venir lorsque tu vas tenter l'ouverture.

Typiquement une requête simple va toujours avoir plus ou moins cette forme là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
try
{
	using (IDbConnection connection = new SqlConnection(myConnectionString))
	{
		using (IDbCommand command = connection.CreateCommand())
		{
			// preparation de la commande
			command.CommandText = "blablabla";
			command.CommandType = CommandType.Text;
			// préparation des paramétres ..
			IDbDataParameter param1 = command.CreateParameter();
			param1.ParameterName = "@nom_du_param1";
			param1.Value = la_valeur;
			command.Parameters.Add(param1);
			// etc.....
			command.Parameters.Add(paramn);
			// Ouverture
			connection.Open();
			// Exéxution (peut etre aussi ExecuteScalar, ExecuteReader ou Fill d'un DataSet)
			command.ExecuteNonQuery();
			// Fermeture
			connection.Close();
		}
	}
}
catch (Exception ex)
{
	// ... traitement de l'exception;
}

Bien sur si c'est une requête en Interrogation, un ExecuteReader ou un ExecuteScalar va être utilisé en lieu et place du ExecuteNonQuery, ou encore un DataAdapter va être utilisé mais cela ne change rien à l'enchainement des lignes de codes (dans le cas d'un DataAdapter, le Open et Close vont encadrer le FIll au lieu du Execute_kekchoz mais c'est tout).

Le catch se chargera de récupérer les erreurs éventuelles (bien sur, tu peux sophistiquer les traitements d'erreurs pour savoir si c'est le Open ou le Execuet qui plante, etc ....).

Eventuellement, dans le cas d'une transaction plusieurs commandes vont être chainées, etc .... mais ça ne change pas grand chose.

Bref, j'ai l'impression que tu soulèves un problème qui n'existe pas ou alors que tu laisses tes connexions ouvertes au délà du scope de la transaction utilisée, ce qui est une faute de programmation.

EDIT : essaye de préciser ton besoin fonctionnel, car j'ai l'impression qu'il y a quelques chose que je ne comprends pas dans ce que tu cherches.

[jorrie]

disons que notre logiciel utilise des bases de données distantes.

On m'a demandé que si un problème de connexion survient je me retrouve pas avec un gros plantage et des messages d'erreurs .

Mon but est que si le logiciel plante à cause d'une connexion a la base de donnée , je puisse fermé les fenetres proprement et d'initialiser le logiciel comme a son lancement

[Bluedeep]

disons que notre logiciel utilise des bases de données distantes.

Ok, comme 99 % des applications de gestion; jusque là, pas de problèmes.

On m'a demandé que si un problème de connexion survient je me retrouve pas avec un gros plantage et des messages d'erreurs .

Les transactions vont justement assurer l'intégrité des données. Ca tombe bien, elles servent à cela.

Mon but est que si le logiciel plante à cause d'une connexion a la base de donnée , je puisse fermé les fenetres proprement et d'initialiser le logiciel comme a son lancement

Bof ..... il suffit donc d'identifier le problème dans le bloc de catch à partir de là, tu fais ce que tu veux.

Mais ré-initialiser l'application sous prétexte qu'un connexion plante (ce qui peut être en général un problème transitioire réseau ou un problème permanent réseau ou externe - arrêt du serveur par exemple) est une idée particuliérement absurde (pour rester poli), à mon avis.

[jorrie]

bien d'accord mais je ne suis pas mon chef ^^.

Bon je vais me debrouiller avec les infos recu merci beaucoup

[Bluedeep]

bien d'accord mais je ne suis pas mon chef ^^.

Bon je vais me debrouiller avec les infos recu merci beaucoup

Je pense que votre vision est faussée pour les raisons suivantes :

- ce n'est pas le boulot d'une application de gestion de faire la supervision du SI (si chaque appli se met à faire sa supervision dans son coin, ça va devenir très vite le bordel).

- superviser les DBMS est une idée particuliérement tordue : il faut s'assurer de la fiabilité du canal de supervision => retour à la case départ.

- qui supervise le superviseur ?

- S'assurer de la haute disponibilité du/des serveurs de DBMS ne relève pas du bricolage; il y deux méthodes éprouvées pour cela : le mirroring et le clustering. Tout le reste ne relève que de solutions "bricolo".

- Si vous avez besoin de superviser les DBMS sous peine de problèmes c'est que votre achitecture applicative est fumeuse au moins pour ce qui est du traitement des erreurs et de la gestion des transactions.

Bref que votre appli s'applique à faire son boulot et notamment à gérer les cas d'erreurs et les transactions proprement et qu'elle laisse le cockpit de supervision et les DBMS faire le leur.

[jorrie]

imaginons que je perd totalement l'accès à ma base de donnée, si je ne permet pas au logiciel de revenir dans sa situation initiale , l'utilisateur va continuer à ouvrir des fenetres ou executer des traitements alors qu'il faudrait mieux que je lui demande de se reconnecter et que tous ce qui etait ouvert au préalable soit fermé comme à l'ouverture du logiciel

[Bluedeep]

imaginons que je perd totalement l'accès à ma base de donnée, si je ne permet pas au logiciel de revenir dans sa situation initiale , l'utilisateur va continuer à ouvrir des fenetres ou executer des traitements alors qu'il faudrait mieux que je lui demande de se reconnecter et que tous ce qui etait ouvert au préalable soit fermé comme à l'ouverture du logiciel

Mais vous n'avez pas de messages d'erreurs sur votre logiciel ????