2012-10-15 4 views
5

j'utilisais quelque chose à ce jour comme celui-ci pour effectuer des requêtes ma base de données qui fonctionnait parfaitement bien:Oracle performances JDBC ResultSet

PreparedStatement prepStmt = dbCon.prepareStatement(mySql); 
ResultSet rs = prepStmt.executeQuery(); 

Mais je devais utiliser le rs.first(); afin de pouvoir itérer sur mon rs plusieurs fois. Donc, je l'utilise maintenant

PreparedStatement prepStmt = dbCon.prepareStatement(mySql,ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE);  

Ma question est liée à la performance des deux. Qu'est-ce que je perds si j'utilise la deuxième option? L'utilisation de la seconde option aura-t-elle un effet négatif sur le code que j'ai écrit jusqu'à présent? PS: Notez que mon application est une application Web à utilisateurs multiples et à base de données (sur un Weblogic 10.3.4) qui utilise une base de données Oracle 11g principale.

Merci à tous pour votre attention.

MISE À JOUR

Ma taille maximale de reslutset sera inférieure à 1000 lignes et colonnes 15-20

+0

Pourquoi construire une liste '' de ResultSet puis utiliser cette POJO à la place, où vous voulez, n'est pas une option? Il est toujours plus facile de gérer 'List ', par comparaison. Je veux dire des choses de type données, en passant le numéro de colonne, ou le nom, ne s'applique pas là. –

+0

Oui, c'était ce que j'avais en tête lorsque je posais la question. Si j'ai un problème de performance, je vais certainement utiliser cette approche – MaVRoSCy

+0

@AdeelAnsari, qui peut ne pas être une option du resultset est assez grande. – Santosh

Répondre

3

Depuis un curseur Oracle est une structure avant uniquement, afin de simuler un curseur, la Le pilote JDBC doit généralement mettre en cache les résultats dans la mémoire s'il veut s'assurer que les mêmes résultats sont renvoyés lorsque vous parcourez les résultats une deuxième fois. En fonction du nombre et de la taille des résultats renvoyés par la requête, cela peut impliquer une quantité importante de mémoire supplémentaire consommée sur le serveur d'applications. D'un autre côté, cela devrait signifier que l'itération à travers le ResultSet une seconde fois devrait être beaucoup plus efficace que la première fois. Si la mémoire supplémentaire requise est significative, cela dépend de votre application. Vous dites que le plus grand ResultSet aura 1000 lignes. Si vous comprenez que chaque ligne est de 500 octets (cela dépendra évidemment des types de données - si votre ResultSet a juste un tas de nombres, ce serait beaucoup plus petit, s'il contient un tas de longues chaînes de description, il peut être beaucoup plus grand), 1000 lignes représentent 500 kb par utilisateur. Si vous avez 1000 utilisateurs simultanés, ce n'est que 500 Mo de stockage qui n'est probablement pas prohibitif. Par contre, si vous avez 1 million d'utilisateurs simultanés, c'est 500 Go, ce qui signifie probablement que vous achetez quelques nouveaux serveurs. Si vos lignes sont 5000 octets au lieu de 500, alors vous parlez de 5 Go de RAM, ce qui pourrait représenter une grande partie de la mémoire requise sur le serveur d'applications pour exécuter votre application.

+0

Alors, que suggérez-vous? – MaVRoSCy

+0

@MaVRoSCy - Cela dépend de vos besoins. Si votre 'ResultSet' est petit et que vous avez beaucoup de RAM sur les serveurs d'applications, il peut être parfaitement raisonnable d'utiliser des ensembles de résultats défilants. Si ce n'est pas le cas, vous devrez peut-être envisager d'autres options. Certains systèmes peuvent fermer et rouvrir le 'ResultSet' qui oblige Oracle à réexécuter la requête et peut donner des résultats différents si des modifications ont été validées depuis l'exécution de la première requête. Certains systèmes peuvent être en mesure de mettre en cache un sous-ensemble de données (c'est-à-dire un sous-ensemble de colonnes) dans une collection locale. –

9

Si vous utilisez Scrollability (votre deuxième option), faites attention à ceci:

Important: Parce que toutes les lignes de tout jeu de résultats défilante stockés dans le cache côté client, une situation où le jeu de résultats contient de nombreuses lignes , de nombreuses colonnes ou de très grandes colonnes peuvent provoquer l'échec de la machine virtuelle Java (JVM) côté client. Ne spécifiez pas de défilement pour un grand ensemble de résultats .

Source: Oracle Database JDBC Developer's Guide and Reference

+0

C'était vraiment utile, merci – MaVRoSCy

+0

De rien! –