Discussion :

[jiryaia]

*petite erreur, ca a posté alors que je n'avais pas finit *

je confirme de base comme ca, ca ne fonctionne pas :p
Mais par contre ca met bien sur la voie !

J'ai adapté mon code en fonction de ton exemple:
ca donne quelque chose comme ca :

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
30
31
32
33
34
35
 
public class ConnDBT
{
    public DbDataAdapter dtadap;
    public DbConnection conn;
	public ConnDBT()
	{
        DbProviderFactory dbpf = DbProviderFactories.GetFactory(ConfigurationManager.ConnectionStrings["ProviderStingtoto"].ConnectionString);
        conn = dbpf.CreateConnection();
        dtadap = dbpf.CreateDataAdapter();
        conn.ConnectionString = ConfigurationManager.ConnectionStrings["ConnectionStringtoto"].ConnectionString;
        dtadap.SelectCommand = conn.CreateCommand();
        dtadap.InsertCommand = conn.CreateCommand();
        dtadap.UpdateCommand = conn.CreateCommand();
	}
 
    // Mes fonctions de requete
    public DataTable SelectCategorieTLP()
    {
        using (conn)
        {
            using (dtadap)
            {
                   DataTable tabtlp = new DataTable();
                   conn.Open();
                   dtadap.SelectCommand.CommandText = "SELECT * FROM Categorie WHERE obsolete= false";
                   dtadap.Fill(tabtlp);
                   conn.Close();
                   return (tabtlp);
            } 
        }
    }
    // Autre fonction
//
}

que j'utilise toujours comme ca :

Code :

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

1
2
3
4
5
6
 
DataTable tabtlp;
        ConnDBT conn = new ConnDBT();
        tabtlp = conn.SelectCategorieTLP();
        this.CategorieRepeater.DataSource = tabtlp;
        this.CategorieRepeater.DataBind();

la ca fonctionne mais il y a un moyen de controler justement le pool ?

[Philippe Vialatte]

la ca fonctionne mais il y a un moyen de controler justement le pool ?

Regarde si tes connections restent ouvertes depuis Sql server

[jiryaia]

Malheureusement je boss sur une base access
( et oui yen a encore ...) , mais en gros meme principe,
il y a un fichier temporaire qui se crée quand il y a connexion a la base.

Donc ce qui est sur c'est que ca a bien fait quelque chose puisque je ne voi plus le fichier en question apparaitre quand je fais des accés via le site.

Je vais creusé un peu pour en etre sur mais ca l'air de le faire.

Un grand merci pour le coup de main !

@+

[Immobilis]

Regarde si tes connections restent ouvertes depuis Sql server

Le pool n'est pas sur le serveur SQL mais le client (IIS dans ce cas). Pour raccourcir le temps de latence d'un port ouvert sur SQL server il faut le configurer.

D'un point de vue général: tout objet qui utilise des objets disposables doit lui même être disposable (ie implémenter l'interface). Comme les objets d'accès aux données sont disposables ta classe devrait l'être aussi. Il y a pas mal de patterns sur le net. Si c'est fait correctement tu n'auras plus de soucis avec les connections.

Si tu ouvres la connexion dans le constructeur elle ne sera détruite que lorsque la classe sera détruite par le GC. Utilise plutôt le modèle de Philippe Vialatte.

A+

[Philippe Vialatte]

Malheureusement je boss sur une base access
( et oui yen a encore ...) , mais en gros meme principe,
il y a un fichier temporaire qui se crée quand il y a connexion a la base.

JE compatis, j'ai été dans ce cas trop longtemps

Le pool n'est pas sur le serveur SQL mais le client (IIS dans ce cas). Pour raccourcir le temps de latence d'un port ouvert sur SQL server il faut le configurer.

Oui, le pool est sur le serveur IIS, mais depuis IIs, tu ne peux pas savoir combien de connections "fantomes" existent, que depuis SQL Server, tu peux connaitre le nombre de connexions ouvertes à un instant t

[jiryaia]

Bien le bonjour,

aprés quelques tests;

Quand la connexion est ouverte dans le constructeur de la class, effectivement aprés un certain temps d'innactivité le GC ferme la connexion.

Mais par contre comme dit Immobilis il y a une latence qui peut posser problème, ca aussi c'est vécu, les connexions sont effectivement fermées aprés cette latence donc, l'application ne plante pas, mais il arrive que les accés à la base soient simplement inaccéssible, et remis a disposition quand le pool est libéré, soit un site sans base de donnée pendant en générale 10 à 20 minutes.
Si le pool est saturé par contre plus d'accés la base jusqu'a la purge du pool qui se fait apparement assez souvant trés tot le matin, pour mon herbergeur a 7h00 tous les matins.
(ca aussi vécu pas avec les connexions mal fermées mais a cause d'une base access trop volumineuse ... )

Alors oui c'est configurable, mais quel interet quand il suffit de fermer proprement la connexion "a l'ancienne" avec le conn.Close(); ?

Le GC ne devrait pas etre utilisé plutot comme une sécurité que comme une méthode ?

*j'éspère que je dis pas trop de bétise*

Bref juste pour un visu plus explicite, j'exporterai ma base vers SQL Server d'ici à ce week-end.

Merci a tous !

[Philippe Vialatte]

Le GC ne devrait pas etre utilisé plutot comme une sécurité que comme une méthode ?

*j'éspère que je dis pas trop de bétise*

Bah si, justement, d'ou l'interet de passer par des using, qui t'assurent que la connection est fermée à la fin du using.

Par contre, il faut dans ce cas définir la variable dans le using

[CUCARACHA]

Perso j'ai une technique exotique qui fonctionne à chaque fois (mais c'est sale ). C'était il y a un an puisque depuis je suis passé à EF.

Je crée ma connexion au début du page load et je la ferme à la fin du page load (ou dans les évènements des contrôles). On ne peut pas appeler un using.

Ensuite, je passe la connexion en paramètre (par référence) à toutes mes méthodes d'accès aux données. Donc, c'est toujours la même qui est utilisée par toutes les méthodes de la page.
Je redescends toutes mes données dans une structure sérializable puis je fais tous mes traitements à postériori.

Je n'ai jamais eu de conflit de connexion (peut être est-ce de lan chance, mais sans la chance, que serions nous ?)

Bien à vous

Laurent

[Immobilis]

Oui, le pool est sur le serveur IIS, mais depuis IIs, tu ne peux pas savoir combien de connections "fantomes" existent

Non effectivement.

que depuis SQL Server, tu peux connaitre le nombre de connexions ouvertes à un instant t

Ce ne sont pas des connections ouvertes, mais plutôt des ports reservés.

Quand la connexion est ouverte dans le constructeur de la class, effectivement aprés un certain temps d'innactivité le GC ferme la connexion.

Le GC devrait fermer la connexion une fois que la page est affichée. une page web est "morte" quand elle arrive chez le client.

mais il arrive que les accés à la base soient simplement inaccéssible, et remis a disposition quand le pool est libéré, soit un site sans base de donnée pendant en générale 10 à 20 minutes.

Tant que ça?? Ce n'est pas normal. La durée par défaut est de 90s sur SQL Server. Sur Access c'est certainement parce que la base est restée bloquée à cause du nombre d'utilisateurs

Si le pool est saturé par contre plus d'accés la base jusqu'a la purge du pool qui se fait apparement assez souvant trés tot le matin, pour mon herbergeur a 7h00 tous les matins.

Bizarre...

(ca aussi vécu pas avec les connexions mal fermées mais a cause d'une base access trop volumineuse ... )

Alors oui c'est configurable, mais quel interet quand il suffit de fermer proprement la connexion "a l'ancienne" avec le conn.Close(); ?

Dans le cas d'Access c'est surtout un problème d'accès concurrents. Au bout d'un certain nombre d'utilisateurs la base se bloque complètement! Pour l'avoir vécu il fallait que je supprime manuellement le fichier temporaire de lock.

Bref juste pour un visu plus explicite, j'exporterai ma base vers SQL Server d'ici à ce week-end.

Bonne idée, mais il faut tout de même rester prudent. SQL possède par défaut un peu moins de 4000 connections utilisateurs disponibles. Il est tout à fait possible de les saturer avec une boucle. C'est pour cela que par défaut le pool de connection de IIS est limité à un peu plus d'une centaine. Une fois le plafond atteind tu as une belle erreur .Net.

Je n'ai jamais eu de conflit de connexion (peut être est-ce de lan chance, mais sans la chance, que serions nous ?)

Il faut juste faire un peu attention Ceci par exemple plante parce que la connexion est en cours d'utilisation

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
private void MaFonctionDo(SqlConnection connection, int i)
{
    SqlCommand command = new SqlCommand("SELECT * FROM MATABLE2 WHERE ID = " + i.ToString(), connection);
 
    SqlDataReader reader = command.ExecuteReader();
    while (reader.Read())
    {
        // Do something
    }
}
 
protected void Page_Load(object sender, EventArgs e)
{
    SqlConnection connection = new SqlConnection("machaine");
    connection.Open();
    SqlCommand command = new SqlCommand("SELECT * FROM MATABLE", connection);
 
    SqlDataReader reader = command.ExecuteReader();
    while (reader.Read())
    {
        MaFonctionDo(connection, (int)reader[0]);
    }
}

Personnellement, dans un modèle 3-tiers, j'ai une classe de connexion aux données. Grâce à l'implémentation de l'interface IDisposable, j'ouvre une connexion, créé une commande, une transaction, une collection de paramètres dans le constructeur des mes classes et détruis le tout dans le destructeur. Il y a un pattern particulier pour ça. Ensuite toutes les classes qui utilisent un objet disposable doivent elle-même être disposables, ou alors il faut utiliser un using.

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
using System;
using System.Collections.Generic;
using System.Text;
using System.Data;
using System.Data.Common;
using BusinessObjects;
 
namespace DataAccessLayer
{
    public class TemplateProvider : IDisposable
    {
        private DBFactory _db = null;
        // Variable to track if Dispose has been called
        private bool disposed = false;
 
        #region Constructor
 
        public TemplateProvider(DBProperty prop)
        {
            _db = new DBFactory(prop);
        }
 
        #endregion
 
 
        #region IDisposable
 
        /// <summary>
        /// <c>TemplateProvider</c> creates members of the following IDisposable types: 
        /// <c>DBFactory</c>. If <c>TemplateProvider</c> has previously shipped,
        /// adding new members that implement IDisposable to this 
        /// type is considered a breaking change to existing consumers.
        /// </summary>
        public void Dispose()
        {
            // Check if Dispose has already been called 
            if (!disposed)
            {
                // Call the overridden Dispose method that contains common cleanup code
                // Pass true to indicate that it is called from Dispose
                Dispose(true);
                // Prevent subsequent finalization of this object. This is not needed 
                // because managed and unmanaged resources have been explicitly released
                GC.SuppressFinalize(this);
            }
            disposed = true;
        }
 
        /// <summary>
        /// Implement a finalizer by using destructor style syntax.
        /// Use of this destructor will be done by GC.
        /// </summary>
        ~TemplateProvider()
        {
            // Call the overridden Dispose method that contains common cleanup code
            // Pass false to indicate the it is not called from Dispose
            Dispose(false);
        }
 
        /// <summary>
        /// Implement the override Dispose method that will contain common cleanup functionality
        /// </summary>
        /// <param name="disposing">This parameter indicates whether disposition of object is managed by user's coding or GC cleanup.</param>
        private void Dispose(bool disposing)
        {
            if (disposing)
            {
                _db.Dispose();
            }
        }
 
        #endregion
    }
}

Maintenant, avec LINQ, c'est géré tout seul.

A+