Le moyen privilégié pour interroger une base de données plusieurs fois?

Lors de l'utilisation de JDBC Java, la méthode généralement acceptée de l'interrogation d'une base de données est d'acquérir une connexion, créer une déclaration de la connexion, puis vous exécutez une requête à partir de cette déclaration.

//load driver
Connection con = DriverManager.getConnection(..);
Statement stmt = con.createStatement();
ResultSet result = stmt.executeQuery("SELECT..");
//...

Cependant, je ne suis pas sûr de la façon de traiter une deuxième requête de la même base de données.

Peut-être une autre requête sera exécutée en toute sécurité sur le même Statement objet, ou une autre déclaration doit être créé à partir de la Connection objet afin d'en exécuter une autre requête?
Si le même Statement objet peut être utilisé pour de multiples requêtes, quel est le but de la Statement classe (puisqu'il serait alors plus logique pour un Connection.executeQuery() méthode d'exister)?

Pour la première partie, avez-vous essayez de le faire vous-même? Avez-vous eu des exceptions ou indésirables de sortie?
Il y a des tonnes d'exemples sur le web. Vous pouvez regarder là-bas, essayez vous-même et si vous avez une exception ou des troubles d'améliorer votre question, afin que nous puissions vous aider plus précis.
Je n'ai pas, mais je suis quasi certaine que plusieurs requêtes peuvent être exécutées à partir de la même option d'Instruction, ce qui m'amène à me demander si il y a des inconvénients ou des problèmes de sécurité avec le faire (question 1), et comme un résultat, ce qui est le point de la Déclaration de la classe (question 2).

OriginalL'auteur Vulcan | 2012-10-18

7

Oui, vous pouvez réutiliser le Statement objet, mais le ResultSet objets retournés par la executeQuery ferme déjà ouvert les jeux de résultats.

Voir le javadoc pour l'explication

Par défaut, un seul objet ResultSet par la Déclaration de l'objet peut être ouvert
dans le même temps. Par conséquent, si la lecture d'un objet ResultSet est
entrelacés avec la lecture de l'autre, chacun doit avoir été généré
par différents Déclaration des objets. Toutes les méthodes d'exécution dans l'état
interface implicitement à proximité d'une déclaration actuel de l'objet ResultSet si un
ouvrir un existe.

Donc ce qui suit se produit:
```
//load driver
Connection con = DriverManager.getConnection(..);
Statement stmt = con.createStatement();
ResultSet result = stmt.executeQuery("select ..");
//do something with result ... or not
ResultSet result2 = stmt.executeQuery("select ...");
//result is now closed, you cannot read from it anymore
//do something with result2
stmt.close(); //will close the resultset bound to it
```
Par exemple, vous pouvez trouver une implémentation open source de Déclaration dans les jTDS projet.
Dans le L'énoncé.executeQuery() la méthode vous pouvez voir un appel à initialize() que ferme tous les jeux de résultats déjà ouvert
```
protected void initialize() throws SQLException {
    updateCount = -1;
    resultQueue.clear();
    genKeyResultSet = null;
    tds.clearResponseQueue();
    //FIXME Should old exceptions found now be thrown instead of lost?
    messages.exceptions = null;
    messages.clearWarnings();
    closeAllResultSets();
}
```
Si toutes les méthodes d'exécution implicitement à proximité une déclaration actuelle du jeu de résultats (si ouverte), est-il nécessaire de fermer explicitement un jeu de résultats avant d'exécuter une autre requête?
vous avez raison, comme vous l'avez remarqué, et comme il est dit dans la javadoc, le execute*() méthodes sur un Statement semble fermer les ResultSet qui en découle, de sorte que, dans la pratique, il n'est pas obligatoire d'appel close() sur elle avant de délivrer un nouveau exécuter, mais il est de bonne pratique pour fermer les ressources que vous avez ouvert.
Voir mon montage pour le jTDS implémentation open source comme un exemple.
Merci. Marquage de cette réponse acceptée parce que je me sens le plus répondu avec précision à la question d'origine, bien que j'apprécie également les réponses des autres, que chacun m'a appris quelque chose de nouveau.

OriginalL'auteur Alex
3

Par programmation, vous pouvez réutiliser la même connexion et le même énoncé pour plus d'une requête et de fermer la déclaration et le lien à la fin.

Cependant, ce n'est pas une bonne pratique. La performance de l'Application est très sensible à la façon de la base de données est accessible. Idéalement, chaque connexion doit être ouverte pour que le moins de temps possible. Ensuite, les connexions doivent être mis en commun. En passant par qui, vous placez chaque requête dans un bloc de {open connection, create a prepared statement, run query, close statement, close connection}. C'est aussi la façon dont la plupart des Modèles SQL sont mis en œuvre. Si la simultanéité permet, vous pouvez lancer plusieurs requêtes en même temps à l'aide d'un pool de threads.

Semble raisonnable, mais quel est le raisonnement derrière le garder une connexion ouverte pour le moins de temps possible? Est-il préférable de garder une connexion ouverte à gérer que 10 requêtes par minute, ou d'ouvrir une nouvelle connexion en moyenne une fois toutes les 6 secondes?
Ce n'est pas le même. Vous avez la connexion ouverte le moins de temps et puis retourner à la piscine. La piscine sera de garder la connexion ouverte pour vous. Parce que vous "fermer" la connexion chaque fois que vous êtes sûr que c'est toujours retourné à la piscine. Si vous traitez vous-même, le risque augmente que vous manquez de la fermer et de lancer dans les sessions de base de données ou de la mémoire de poireaux problèmes.

OriginalL'auteur srini.venigalla
2

J'ai une chose à ajouter si vous utilisez la Connexion et de l'Énoncé dans une tige filetée de l'environnement.
Mon expérience montre que stmt.executeQuery(..) est enregistrer pour une utilisation dans un environnement parallèle mais avec la conséquence que chaque requête est sérialisé et traités sequencially, à ne pas céder à toute vitesse-ups.
Donc, il es préférable d'utiliser une nouvelle Connexion (pas de Déclaration) pour chaque thread.

Pour une norme séquentielle de l'environnement de mon expérience a montré que la réutilisation des États n'est pas un problème et jeux de résultats n'a pas besoin d'être fermé manuellement.

J'ai trouvé cela très utile, comme je l'ai suis à l'aide de la Connexion et de l'Énoncé dans une tige filetée de l'environnement. Combiné avec ce que Udo Lieu's réponse conseille, je me sens comme je l'ai appris ce dont j'ai besoin pour le multi-thread connexions de base de données.

OriginalL'auteur Sebastian
1

Je ne serais pas s'inquiéter à propos de la création de nouveaux états. Cependant l'ouverture d'une connexion de base de données peut être consommatrice de ressources et d'ouverture et de fermeture des connexions a un impact sur les performances.

Laissant les connexions dans certains autonomie de gestion de la voie est généralement assez mauvais.

Vous devriez envisager d'utiliser le regroupement de connexion. Vous avez généralement question de proximité d'un commando, mais seulement de donner à cette connexion de retour à la piscine. Lorsque vous demandez une nouvelle connexion puis il va réutiliser la connexion que vous avez donné plus tôt.

Vous pouvez avoir différents états pour une connexion. Une instruction est une mise en œuvre et une interface. Selon ce que vous devez-vous parfois envie d'une utilisation d'un CallableStatment. Certains un peu de logique peuvent être réutilisés lorsque requis.

Merci, je n'avais jamais rencontré le regroupement de connexions avant, et il semble comme un outil très utile de concept que je vais utiliser dans mon application serveur.
Si le serveur est une application web puis le serveur d'application peut faire la connexion de la mutualisation. La configuration doit être décrit dans votre serveur d'applications. Sinon, vous pouvez utiliser commons.apache.org/dbcp ou certains autres outils de votre choix.
Mes excuses, je ne crois pas que j'ai été clair avec cette affirmation; c'est tout simplement une application Java d'hébergement d'un serveur de socket pour les sockets client à se connecter.

OriginalL'auteur Udo Held
1

Généralement, c'est une déclaration pour une seule requête. Il pourrait ne pas être nécessaire de le faire, mais lors de l'écriture d'application réelle, vous ne voulez pas répéter les mêmes étapes, encore et encore. C'est à l'encontre de la SEC principal, en plus, il sera également obtenir plus complexes à mesure que la demande augmente.

C'est bon pour écrire des objets qui vont gérer ce genre de bas niveau (répétitif) des animaux, et de fournir des méthodes différentes pour l'accès db en fournissant les requêtes.

OriginalL'auteur Bhesh Gurung
1

Eh bien, c'est pourquoi nous avons le concept de classes dans la programmation orientée objet . Une classe définit membres constitutifs qui permettent à ses instances pour avoir l'état et le comportement. Voici la déclaration traite de tout ce qui est lié à une instruction sql. Il y a donc beaucoup plus de fonction que l'on peut effectuer comme lot de requêtes, etc.

OriginalL'auteur Bhanu Kaushik

Vous devez vous connecter pour publier un commentaire.