Discussion :

[wmenant]

bonjour à tous,

Je souhaiterais développer une application qui extrait des emails depuis Exchange et les insère les informations dans une base de données, mais avant de me lancer, je souhaiterais eclaircir quelques points...

pouvez vous m'aider ou me conseiller quand à la façon de développer l'application, sachant qu'il y aura un client windows (console d'administration), et un service WCF (service d'extraction des emails).

La ou je bloque un peu, c'est sur la gestion des connexions SQL. Sachant que je souhaite utiliser postgreSQL, je ne sais pas trop si je dois ouvrir une connexion pour chaque thread, ou utiliser une connexion pour l'ensemble des threads, sachant que je souhaite utiliser les transactions (TransactionScope)....

De plus, j'ai regardé un peu la doc de postgreSQL et j'ai un peu de mal avec les paramètres "max_connexions" et "max_prepared_transactions"...

Encore merci pour vos conseils.

[StringBuilder]

Sans plus d'informations (et ça tombe bien, on frise la limite de mes connaissances ) je dirais les généralités suivantes :
- .NET et son GC font automatiquement du pooling et de la réutilisation de connexions
- La plupart du temps, les connecteurs de base de données supportent aussi des mécanismes automatisés de pooling (vérifier avec PostgreSQL, mais je suis presque certain que c'est le cas)

Ainsi :
- Lorsqu'une méthode de n'importe quel thread Close() une connexion (même explicitement) et libère la ressource Dispose() (même explicitement) la connexion est récupérée par le GC et remise en pool sans forcément être fermée ni terminée.
- Lorsqu'une méthode de n'importe quel thread Open() une connexion, si elle comporte la même chaîne de connexion qu'une connection en pool (même base, même utilisateur, même paramètres) alors celle du pool est réutilisée.

Par conséquent :
- Multithread ou non, il faut systématiquement utiliser using() sur tous les objets de bdd (connexion, transaction, command notamment)
- Il faut systématiquement Open() et Close() immédiatement avant et après utilisation (bon, évidement, si t'as 4 requêtes à faire à la suite, tu fermes pas la connexion entre les requêtes...)
- Lors de l'ouverture d'une nouvelle connexion, le CG peut décider de réutiliser une autre connexion déjà ouverte et en cours d'utilisation par un autre thread. Il cloisonne alors les deux traitements dans des transactions séparées.

Au niveau des transactions, il faut savoir :
- Que lorsque tu fais un Close() (même si la connexion reste ouverte et remise en pool) un Rollback est fait sur toutes les transaction en cours
- Qu'une transaction ouverte peut potentiellement générer les LOCKS dans la base, d'où l'intéret de conserver les objets ouverts le moins longtemps possible

Après, on a parfois besoin de gérer des locks "manuellement", et là on est obligé de conserver des connexions et transactions ouvertes pendant longtemps. Mais ça doit se faire sciemment, et à bon escient.
Exemple : http://www.developpez.net/forums/d11...rrous-rowlock/

[wmenant]

Merci StringBuilder; ça commence à devenir un peu plus claire dans ma tête...

J'ai commencé un peu cet après midi, et comme ut le mentionnes

Que lorsque tu fais un Close() (même si la connexion reste ouverte et remise en pool) un Rollback est fait sur toutes les transaction en cours

J'utilise bien le using avec TransactionScope, puis le Complete une fois la transaction terminée (ou le close en cas de problème et donc, le rollback). J'ai rajouté le Dispose, même si c'est explicite.

Par contre, j'ai pas pensé à utiliser le using pour les commandes (et j'en ai pas mal d'ailleurs.... Est-ce que tu as un exemple d'utilisation de plusieurs commandes avec un using s'il te plait ?

Je suis en train de me renseigner sur la façon dont PostgreSQL fonctionne et sur ses paramètres de connexions et de pooling (c'est possible avec PostgreSQL, mais désactivé par défaut avec le paramètre max_prepared_transactions qui est à 0, si j'ai bien tout compris )...

Encore merci pour ton aide !

[StringBuilder]

Bah le using sur un command n'est pas compliqué, je ne vois pas trop la question :

Code :

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

1
2
3
4
5
 
using (SqlCommand cmd = cnx.CreateCommand())
{
    [...]
}

Et quand tu as besoin de faire plusieurs requêtes à la suite, utilise au maximum le même command.
N'oublie pas de faire un cmd.Parameters.Clear() à chaque fois pour vider les paramètres (à moins qu'ils ne soient identiques d'une requête à l'autre).

Par contre, tu parles de TransactionScope, et ça, je n'ai aucune idée de ce que c'est, donc je peux pas du tout te conseiller là dessus...

[StringBuilder]

Après avoir regardé rapidement la doc de C#, j'ai compris ce qu'était le transaction scope.

As-tu vraiment besoin de cette fonctionnalité ?

Il s'agit de transactions en dehors du SGBD. Cela implique donc que :
- Ca crée une transaction dans le SGBD
- MAIS AUSSI dans ton programme. C'est à dire que si tu annules la transaction tu rollback dans la base, mais aussi tout ce que ton programme à fait (modification de variables, de fichiers,etc.) Ca me semble un peu lourd si ce n'est pas pour gérer des cas très précis.

Je pense que tu dois pouvoir te contenter des transactions du SGBD, à savoir l'objet SqlTransaction (ou PgTransaction, je ne sais pas comment sont préfixées les classes pour Posgresql)

[BenoitM]

Il s'agit de transactions en dehors du SGBD. Cela implique donc que :
- Ca crée une transaction dans le SGBD
- MAIS AUSSI dans ton programme. C'est à dire que si tu annules la transaction tu rollback dans la base, mais aussi tout ce que ton programme à fait (modification de variables, de fichiers,etc.) Ca me semble un peu lourd si ce n'est pas pour gérer des cas très précis.

Euh je pense pas, pour moi l'avantage du TransactionScoope c'est que tu peux imbriquer des transactions

Exemple tu as une Methode1 qui fait appelle à une transaction et une Méthode2 qui fait appelle aussi a une transaction
Après tu as une Methode3 qui commence une transaction et qui appelle Methode1 et Methode2 et qui commit la transaction

Sans transaction scope la Methode 1 et 2 auraient toute deux sauvés les modifications alors que Methode3 fait un rollback