JDBC et mémoire de la JVM

Bonjour a tous.
J'ai une appli qui gère des recopies de base vers base.
Je souhaite compter a partir du ResultSet le nombre de lignes, de manière a pouvoir renseigner une ProgressBar sur l'état d'avancement du transfert.

Il existe plusieurs solutions pour compter ce nombre de ligne.
Soit faire un count
Soit utiliser un scrollable ResultSet
soit en utilisant un RowSet...dans mon cas un OracleCacheRowSet

Toutes ces méthodes fonctionnent bien pour des petites requêtes...
Seulement certains de nos traitements gère beaucoup de ligne.
Un count(*) n'est pas une solution envisageable pour nous, car les requêtes de selection peuvent durer jusqu'a 20 min, donc multiplier ce nombre par deux juste pour avoir un suivi...c'est pas top.
Pour les deux autres solutions...j'abouti a un magnifique OutOfMemoryError...
En effet, j'ai regardé avec JProbe l'état de la mémoire de la JVM
Dans le cas d'un ResultSet scrollable...la mémoire utilisée augmente progressivement jusqu'au OutOfMemoryError lors de la boucle sur le ResultSet.

Quand au RowSet, c'est pire, en effet, il rempli lors de l'éxecution de la requête la mémoire jusqu'au OutOfMemoryError, sans même entrer dans la boucle rs.next()...

Pour info, en gros, je fais un select dans ma base, puis je boucle sur le resultSet , et pour chaque ligne de ce ResultSet...je fais un insert dans une autre table....

Je souhaite savoir si quelqu'un a déjà rencontré ce problème, et si éventuellement quelqu'un a une astuce pour le régler...

Je tiens a préciser que si j'utilise un resultSet avec pour type TYPE_FORWARD_ONLY je n'ai aucun message d'erreur...ca fonctionne très bien...
(Je reste sous la barre des 5Mo de mémoire de la JVM utilisée, alors qu'avec les deux autres méthodes j'explose les 64Mo).
Je suis aussi au courant qu'il est possible d'augmenter la taille de la mémoire de la JVM... avec l'option -xmx de java...mais je ne trouve pas cela très propre....
Merci d'avance!

Je me dis que si vu que tutilises beaucoup de mémoire, parce que le résultset est totalement chargé en mémoire, il me semble que tu n'aies pas d'autre choix d'augmenter la taille mémoire de ta JVM...

Pourquoi n'utilises-tu pas un "Insert into select" ou essaie d'effectue ton opération à l'aide "stored procedure" (une procédure qui est exécuté par la banque de données)?

Citation:

---

Envoyé par tomca

Pour info, en gros, je fais un select dans ma base, puis je boucle sur le resultSet , et pour chaque ligne de ce ResultSet...je fais un insert dans une autre table....

---

ça tu peux le faire directement en SQL comme l'a dit Jowo :roll:

Mais est ce qu'il fait un insert dans la meme base ou dans une autre base ?

Merci a tous de votre aide!

Pour les insert into select...c'est pas tellement possible.

En fait, mon appli c'est un ETL...en gros, on définie dans un fichier xml la source de données, et la destination des données...le truc, c'est que tout est dynamique...en gros, les données obtenues via le select de source, sont réorganisée et insérées dans dans base, d'autres tables, etc...
Elles peuvent être aussi transcodées, utiliser des constantes...etc....en gros, je peux pas le faire directement en SQL... (cf remarque remika)
Le fait que les requêtes d'insert soit dynamique ne me permet pas de jouer avec des insert into select...
(par exemple, on peux avoir un select sur trois champs depuis la table 1, et faire des inserts avec les deux premiers sur la table 2 et le troisième champ pour la table 3...)

Augmenter la mémoire de la JVM ne me semble pas régler de manière définitive mon problème...car rien ne me dis que je vais pas pondre un jour une requêtes qui fait exploser la mémoire, même si je l'ai augmentée...(on travail avec des très gros flots de données)

Par contre, en ce qui concerne les procédures stockées, est-il possible de stocker l'insert dynamique à l'aide de JDBC? Quelqu'un connait t'il l'adresse d'un bon tuto la dessus? merci jowo pour cette idée...a creuser...

benratti...en fait, tout est dynamique, donc les inserts peuvent être faits sur d'autres tables, mais aussi sur d'autres bases....et les champs retournée par mon select ne sont pas forcement tous insérés dans la même table....