J'utilisais toujours JDBC dans Javase sur un environnement unique. Mais maintenant, j'ai besoin d'utiliser un pool de connexion et de laisser plusieurs threads à avoir une interaction avec la base de données (MSSQL et Oracle) et j'ai du mal à essayer de le faire car il semble que je manque de désavoubles fondamental de l'API. AFAIK Après la connexion et la connexion à une connexion code> code> représente une connexion TCP / IP phisique à la base de données. Il crée Sinon, et après avoir configuré la piscine quelque chose comme ceci: p> BTW, où dois-je définir la taille du pool de connexion? p> li>
est-ce ce que je ferais dans chaque fil afin d'utiliser correctement la connexion? p> li>
ul> // THEAD PROCÉDÉ DE RUN P> Merci beaucoup et pardonne à mon mauvais anglais s'il vous plaît. p> p> instruction code> (s) (s) (s) SQL) avec la ou les interactions SQL avec la base de données sur la connexion code>. P>
instruction code> niveau. Li>
Connection code> Créez des instructions et donnez-la à des threads différents afin de permettre à chacun d'utiliser l'utilisation de cette déclaration code>? LI>
ul>
Connection conn = ods.getConnection();
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("the sql");
// do what I need to do with rs
rs.close();
int updateStatus = stmt.executeUpdate("the update");
stmt.close();
conn.close();
7 Réponses :
Transactions se produisent au niveau de la connexion.
non. Habituellement, le pilote JDBC veillera à ce que vous ne puissiez pas exécuter une deuxième instruction sur la même connexion, tandis qu'une autre est active.
Si vous avez besoin de la mise en commun de la connexion, essayez le Frame-DBCP . Il offre une manipulation de défaillance assez décente (comme le notant des connexions sales et des connexions qui n'ont pas été retournées par code client).
Tant que votre code: enveloppez toujours le code dans Ce code veillera à ce que toutes les connexions, etc., sont toujours correctement fermées et que toute exception pendant la fermeture ne va pas Masquer une erreur précédente. Essayer {...} enfin {...} :
Oh Boy, j'aime Java, Everithing a un cadre: D Merci Aaron pour la réponse. Mais bien, à propos de ce que le cadre fait avec des connexions obsolètes, n'est-ce pas quelque chose qu'une implémentation de pool (pilote Oracle ou MSSQL) devrait le faire par défaut?
"Devrait"! = "fait"! = "fait bien". Vous pouvez définir un délai d'attente dans le DBCP qui dit "si la connexion n'était pas retournée après une heure, il y a un bogue dans le client, alors réutilisez-le". En ce qui concerne "Stale", vous devez fournir SQL personnalisé pour vérifier si une connexion est morte. Ce serait bien si JDBC définirait cela, mais la plupart des fournisseurs de DB ne sont même pas la peine de soutenir une grande partie de la spécification JDBC. Par exemple, à Oracle, l'horodatage n'est pas un java.sql.tmestamp.
Je pense que vous devriez commencer avec le soleil Tutoriel sur la mise en commun de la connexion. En outre, il existe de nombreuses implémentations de la mise en commun de la connexion, une source ouverte, y compris un de Apache . Vous devriez vraiment commencer là plutôt que de réinventer la roue ici.
Em, désolé, je ne voulais pas réinventer quelque chose. Le didacticiel suggère une enveloppe de connexion JDCConnectionManager. Mais les conducteurs que j'utilise ont déjà leur mise en œuvre de la source de données groupée.
Quels pilotes utilisez-vous? Aussi, avez-vous regardé la mise en œuvre de Apache? Si vous avez besoin de plus que le JDBC de base, cela peut résoudre votre problème pour vous.
OJDBC14.jar et JTDS-1.2.2.2.2.jar. Pourquoi devrais-je essayer la mise en œuvre du pool Apache si le conducteur le fournit déjà?
Eh bien, vous avez deux bases de données différentes que vous vous connectez à, que les implémentations Apache (ou potentiellement d'autres) vous donneront la capacité d'avoir un pool qui interagit avec l'une ou l'autre. Mais je ne suis plus clair sur votre question. Au début, vous sembliez écrire votre propre mise en œuvre du pool (comme le tutoriel Sun Sun). Maintenant, vous semblez vouloir utiliser un existant. Je ne sais pas ce qu'Alacle a, mais JTDS vous donne simplement une connexion appropriée pour une piscine, elle ne vous donne pas la mise en œuvre actuelle de la piscine.
Les pools de connexion décorent des instances de connexion et de déclaration avec leurs propres implémentations d'emballage. Lorsque vous appelez Fermer sur une connexion, vous le relâchez simplement à la piscine. Lorsque vous appelez Fermer sur une déclaration préparée, vous le publiez simplement au cache de la déclaration de la connexion. Lorsque vous préparez une instruction, vous pouvez simplement rechercher une instance d'instruction cachée à partir de la connexion. Tout cela est caché de la vue afin que vous n'ayez pas à vous en soucier.
Lorsqu'une connexion est donnée à un client, il n'est plus disponible pour un autre client à utiliser jusqu'à ce que la connexion soit libérée dans la piscine. Vous venez généralement de chercher des connexions lorsque vous en avez besoin, puis de les renvoyer dès que vous avez fini avec eux. Parce que les connexions sont tenues ouvertes dans la piscine, il y a peu de frais généraux dans la récupération et la libération de connexions.
Vous devez utiliser une connexion de la piscine tout comme vous seriez une connexion JBDC unique et suivez les meilleures pratiques concernant la fermeture des ressources afin que vous ne fassiez pas de connexions ni de déclarations. Voir l'essai / attraper / enfin des exemples dans certaines des autres réponses.
Les piscines peuvent gérer les ressources de connexion et les tester avant de les remettre aux clients pour s'assurer qu'ils ne sont pas obsolètes. Aussi une piscine créera et détruire des connexions au besoin.
Wow!, Merci Teabot une dernière chose, une fois que vous avez une connexion. Pourquoi l'API a-t-elle divisé les opérations à effectuer dans la base de données dans un objet de relevé au lieu d'utiliser l'objet de connexion? Je dois cela pour les déclarations préparées. Mais pour les déclarations normales, est-ce juste de laisser le développeur a permis de dire n opérations que la migue est exécutée ou non, ou peut être exécutée plusieurs fois, c'est juste pour cela?
Juste deviner, mais: comme vous le réalisez apparemment, les systématisations doivent être distinctes des connexions car il pourrait y avoir plus d'une prêté préparée par connexion. Je suppose donc que les personnes Java ont fait des déclarations distinctes pour les conserver parallèlement à la préparation. Sinon, vous auriez un tas de «fonctions de déclaration» en relation, puis un autre groupe complet de préparation. Cela gâcherait l'arbre d'héritage de la déclaration et de la préparation. Comme je le dis, spéculer simplement. Si quelqu'un a une source faisant autorité à ce sujet, je serais amusé de l'entendre.
Vous ne pouvez conserver qu'une seule déclaration ouverte sur une connexion donnée. Créer plus d'une connexion à l'aide d'un pool de connexion n'est pas si difficile, bien que la voie à suivre consiste à utiliser l'une des plus grandes utilisées là-bas.
En outre, si vous allez aller la voie à la norme JDBC, je vous recommande d'utiliser la déclaration de préparée.
J'utilise Ibatis et hors de la boîte est assez agréable. Apporte quelques autres choses à la table aussi.
bits supplémentaires:
Application Server a tendance à fournir une mise en commun de la connexion et peut être assez intelligent. Si vous utilisez un serveur d'applications, recherchez attentivement ce que vous sortez de la boîte avant d'ajouter quelque chose de votre choix.
Transactions: Si vous avez
Commencer la transaction
Connexion travail Connexion fermée // Signification retour à la piscine
Obtenez la connexion (avec le même niveau d'isolement, etc.) Travail // arrive dans la même transaction
Connexion fermée
commit transaction // commettre tout le travail
connexions et erreurs
Les implémentations de la piscine peuvent être intelligentes. Si une connexion de la piscine éprouve certaines erreurs indiquant que le serveur DB a rebondi, le pool peut choisir de supprimer tous les membres de la piscine.
// Vous obtiendrez
Si vous avez maîtrisé JDBC avec une seule-threading, allez à la multi-threading et les pools de connexion ne devraient pas être une grosse affaire. Tout ce que vous avez à faire différemment est de: 1. Lorsque vous avez besoin d'une connexion, obtenez-le de la piscine au lieu de directement. 2. Chaque thread doit obtenir ses propres connexions.
Pour clarifier le point 2: Si vous obtenez une connexion, puis transmettez-la à plusieurs threads, vous pouvez avoir deux threads essayant d'exécuter des requêtes contre la même connexion en même temps. Java lancera des exceptions à ce sujet. Vous ne pouvez avoir qu'une seule déclaration active par connexion et une requête active (c'est-à-dire Resultset) par déclaration. Si deux threads tiennent à la fois le même objet de connexion, ils risquent de violer rapidement cette règle.
Une autre mise en garde: avec la mise en commun de la connexion, prenez très attention à toujours fermer vos connexions lorsque vous avez terminé. Le gestionnaire de la piscine n'a pas de moyen définitif de savoir quand vous avez terminé avec une connexion, donc si vous échouez à la fermer, il va s'asseoir pendant une longue période, éventuellement éventuellement en fonction du gestionnaire de piscine. Je suivez toujours toujours toujours toutes les "getconnection" avec un bloc d'essai et fermez la connexion dans le bloc enfin. Ensuite, je sais que je l'ai fermé avant la sortie de la fonction.
En plus de cela, tout devrait être le même que ce que vous êtes habitué.
Je ne suis pas sûr que ce soit le problème de la version, "Java lancera des exceptions à ce sujet" n'est pas vrai dans la récente JDBC.
@yuxh désolé, je suppose que ma déclaration était ambiguë. Je ne voulais pas dire que si vous essayez de le faire, Java organisera immédiatement et automatiquement une exception. Je voulais dire, vous êtes susceptible de créer une situation qui provoquera une exception. Vous pourriez avoir un moyen avec une solution donnée d'une application donnée.