La création d'un pool de connexions de base de données

Besoin d'informations sur la création d'un pool de connexion à la base de données (indépendamment de la base de données) , et à quel point ils sont? Quelles sont les conditions où ils peuvent améliorer les performances.

Comment créer explicitement?

OriginalL'auteur Sachin Chourasiya | 2009-11-10

6

Votre question est un peu ambigu:

Voulez-vous homegrow un pool de connexions de mise en œuvre? Si oui, c'est un bon point de départ: http://java.sun.com/developer/onlineTraining/Programming/JDCBook/conpool.html Mais c'est très déconseillé pour les environnements de production. Mieux utiliser un existant et testé le regroupement de connexion API, comme DBCP ou C3P0.

Ou voulez-vous savoir comment utilisation un pool de connexion? Si donc, la réponse dépend de la connexion de mise en commun de l'API que vous utilisez. Il est, heureusement, habituellement disponible sur le site de l'API en question.

Ou voulez-vous savoir quand/pourquoi d'utiliser un pool de connexion? Si oui, il va sûrement améliorer les performances de la connexion si vous avez une longue durée de vie de l'application (par exemple, une webapplication) et vous avez besoin de vous connecter la base de données le plus souvent. La normale JDBC pratique est à savoir: acquérir et fermer la Connection, Statement et ResultSet dans le plus court étendue possible (c'est à dire à l'intérieur de la même méthode de bloc). Car la connexion est assez cher et peut prendre jusqu'à 200 ms de temps, voire plus, à l'aide d'un pool de connexion est beaucoup plus rapide. Il donne des connexions à la demande et prend soin sur le fait de fermer la connexion. Qui ne veut toutefois pas dire que vous pouvez changer la façon dont vous écrivez JDBC, vous avez encore besoin d'acquérir et de les fermer dans le shorest étendue possible. La seule chose que vous avez besoin de changer la façon dont vous acquérir la connexion. E. g. changement de
```
connection = driverManager.getConnection();
```
à
```
connection = connectionPool.getConnection();
```
Plus de changements sont nécessaires aussi longtemps que votre code JDBC est bien écrit.

OriginalL'auteur BalusC
3

La page d'intro à Apache DBCP le résume bien:

La création d'une nouvelle connexion pour chaque
l'utilisateur peut prendre beaucoup de temps (souvent
besoin de plusieurs secondes de l'horloge
temps), afin de réaliser une base de données
opération qui pourrait prendre
millisecondes. L'ouverture d'une connexion par
l'utilisateur peut être irréalisable dans un
public accueilli application Internet
lorsque le nombre d'utilisateurs simultanés
peut être très grande. En conséquence,
les développeurs sont souvent souhaitent partager un
"pool" d'ouvrir des connexions entre tous les
de l'application, les utilisateurs actuels.
Le nombre d'utilisateurs
l'exécution d'une demande à un moment donné
est généralement un très petit pourcentage de
le nombre total d'utilisateurs actifs, et
pendant le traitement des demandes est le seul
temps une connexion de base de données
nécessaire. L'application elle-même les journaux
dans le SGBD, et gère tout utilisateur
les problèmes de compte en interne.

Comment efficace sont-ils ? Dépend de la mise en œuvre. Généralement, je m'attends à une piscine pour instancier des connexions soit au démarrage ou sur demande. La première connexion nécessitera une véritable connexion à la base de données, et par la suite, lorsque vous demandez une connexion, vous êtes donné un existant pool de connexion. Donc, la première demande de connexion prendra le plus de temps, et après vous êtes simplement en tirant des objets d'une collection (très rapide).

Depuis Sachin spécifiquement demandé où les piscines peuvent résoudre les problèmes de performance, je tiens à ajouter que généralement, ils n'ont de sens que dans une application client-serveur, où vous avez moins de connexions des utilisateurs. En particulier, ils ne feraient pas sens dans un client lourd app où vous avez un utilisateur se connectant à une base de données.

OriginalL'auteur Brian Agnew
1

Créer des connexions à des bases de données sont très coûteuses opérations. Les pools de connexion sont des instances de connexions de base de données qui sont créées et mises en cache. Chaque fois qu'une nouvelle connexion à une base de données est souhaitée, l'un de la piscine est utilisée au lieu de créer une nouvelle connexion. Certaines plates-formes comme .NET + SQL Server utiliser des pools de connexion par défaut (vous n'avez pas besoin de créer votre propre). Donc, en gros, ils améliorent la performance par le gain de temps dans la création de nouvelles connexions à chaque fois.

OriginalL'auteur stepanian
1

À l'aide d'un pool de connexion, vous gagnez du temps à chaque accès car la connexion est déjà établie.

En outre, au moins sur Oracle, vous gardez l'compilé déclaration liée à la connexion, donc répétitif de l'exécution de la même instruction SQL est encore plus rapide.

(voir PreparedStatement si vous êtes en Java/JDBC)

Le seul risque de contre-performance, c'est quand vous gardez trop de connexions inactives dans votre piscine, les ressources (de votre côté et sur la base de données) sont gaspillées.

Gardez à l'esprit que les connexions de verrouiller des ressources (threads, tampons) dans le serveur. Et l'établissement d'une connexion est toujours authentifié par un particulier d'utilisateur/mot de passe. Donc, si le regroupement de connexion ne fonctionne que lorsque toutes les connexions utilisent la même base de données compte
Oui, vous avez tout à fait raison avec la base de données unique compte des préoccupations. (Cela peut être un problème lors de la migration à partir de C/S de l'application web par exemple, si l'autorisation est en DB, basé sur l'utilisateur connecté.)

OriginalL'auteur Fouteier
1

Ont un coup d'oeil à BoneCP (http://jolbox.com) dans le repère de la section pour certains numéros. Rappelez-vous que preparedStatements etc, sont liés à une connexion de sorte que vous aurez besoin pour préparer encore et encore si vous avez à traiter avec des connexions de vous-même (un pool de connexion de la mise en cache sera pour vous aussi).

Mon meilleur solution: Utiliser un lazyDataSource qui ne vous donne qu'une connexion lorsque vous en avez vraiment besoin (c'est à dire non à l'aveuglette - si les données peuvent provenir d'une cache, alors vous pouvez éviter de la base de données hit)

OriginalL'auteur wwadge

La création de la base de données du pool de connexion à l'aide de tomcat

1. Tomcat entrez des ressources à l'intérieur : conf/context.xml

Mettre la ressource entrées dans context.xml fichier:

<!-- jdbc/jndiName jndi --> 
<Resource name="jdbc/jndiName" auth="Container" type="javax.sql.DataSource" initialSize="1" maxActive="100" maxIdle="30" maxWait="10000" username="enter username" password="enter password" driverClassName="diver name" url="jdbc database url"/>

2. créer une classe qui va créer le pool de connexion

public class MyConnectionFactory {
    private static String module = "[ QuoteConnectionFactory ]";
    private static QuoteConnectionFactory connectionFactory;

    protected QuoteConnectionFactory() {
    }

    /**
     *
     * @return=>getInstance() is a static method which will return the instance
     *                        of its own class
     */
    public static QuoteConnectionFactory getInstance() {
        if (connectionFactory == null)
            connectionFactory = new QuoteConnectionFactory();
        return connectionFactory;
    }

    /**
     *
     * @param jndiName

     */
    public Connection getConnection(String jndiName) {
        System.out.println("jndiName=======" + jndiName);
        Connection conn = null;
        InitialContext cxt = null;
        DataSource dataSource = null;
        try {
            cxt = new InitialContext();
            Context envContext  = (Context)cxt.lookup("java:/comp/env");
            dataSource = (DataSource)envContext.lookup(jndiName);
        } catch (NamingException e) {

        } catch (Exception e) {

        }

        if (dataSource == null) {

            try {
                conn = dataSource.getConnection();
            } catch (Exception e) {

            }

            System.out.println("connection===================" + conn);
            return conn;
        }
    }

3. modifier web.xml fichier

<resource-ref>
    <description>DB Connection</description>
    <res-ref-name>jdbc/jndiName</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
</resource-ref>

4. Utiliser dans le code

Connection con= QuoteConnectionFactory.getInstance(). getConnection("jndiName");

OriginalL'auteur AKT

0

La création d'une connexion de base de données peut ou peut ne pas être une opération coûteuse, en fonction de votre environnement et que vous voulez faire avec elle.

Si vous allez exécuter une seule très facile de requête, puis de connecter probablement la plus longue (ou plus) de celle de la requête.

Certaines bases de données ont beaucoup plus de connexions que d'autres; si réglée correctement, mysql devrait avoir très peu (au-dessus du temps pour faire une connexion tcp et ne le protocole de poignée de main). Toutefois, si la latence de votre serveur est très élevé, même cela peut être très important (surtout si vous avez l'intention de ne faire que quelques requêtes).

Si vous avez l'intention de faire, de dire, de 100 requêtes, ou un peu de vraiment requêtes lentes, puis le temps de connexion disparaît dans l'insignifiance.

Dans l'ensemble, je dirais ouvrir une nouvelle connexion à chaque fois jusqu'à ce que vous pouvez démontrer que c'est un vrai problème de performance. Utilisant le regroupement de connexion peut conduire à des BUGS, que l'on n'aime pas:
- État de la connexion n'est pas COMPLÈTEMENT réinitialisé après la précédente utilisation de la piscine, de sorte que certains d'état persiste et crée des comportements inattendus résultant d'un bug
- Connexion a été fermée, d'une certaine façon (peut-être par un pare-feu dynamique de délai d'attente) qui ne peut pas être détecté, donc une application tente d'utiliser une connexion fermée, provoquant un retard ou d'échec
Pour un environnement web, vous ne voulez vraiment pas à obtenir une connexion dans une piscine ou autre) au début d'une requête, à effectuer les 100s de requêtes, puis fermez-le. Efficacement les serrures de votre connexion (qui est une ressource limitée, sur le côté de la base de données), et ainsi de limiter le nombre d'utilisateurs de votre site web peut prendre en charge. Beaucoup mieux de prendre de la piscine, utiliser, mettre à revenir dans la piscine (avant tout code qui prend beaucoup de temps). Considérant que l'appui des pools de connexion est à quelques lignes de code (une seule fois dans votre source de données de l'utilitaire du gestionnaire de classe), il n'y a aucune excuse de ne pas les utiliser.

OriginalL'auteur MarkR

Vous devez vous connecter pour publier un commentaire.