Discussion :

[Alkhan]

bonjour,

j'ai une application sur laquelle je ne peux pas pour le moment faire de modification des algos d'accès à la base. Il se trouve que les Resultset sont de type TYPE_SCROLL_INSENSITIVE car certains accès nécessite de se déplacer dans tous les directions voir des déplacements directe via un index.

Comme tout le monde s'en doute c'est formidable sur des petites tables, mais sur des tables de plusieurs million d'enregistrements cela pose un véritable problème de mémoire dû au fait de la mise en cache des enregistrements parcouru !

Comment puis je donc faire pour ne plus avoir ce problème ?
Existe t'il un moyen de limiter le nombre d'enregistrements mis en cache ?

merci d'avance

[tchize_]

Les détails de l'implémentation du SCROLL sont "laissé à la discretion du driver"

Pour dire les choses simplement: si le protocole avec la base de données ne permet pas d'obtenir un curseur bi-directionnel, faudra tout cacher.

Pour te donner une idée, je ne pense pas que le driver pour les base de données oracle fasse autre chose que tout garder en mémoire

Par contre, je connais des drivers qui n'acceptent même pas de te retourner un ResultSet Scrollable.

Bref: ne pas utilser Scrollable + de larges résultats simultanément. Dans ton cas,
La solution la plus sage / propre est de revoir l'implémentation.
La solution la plus simple et qui donne honte le soir devan le miroir est de gaver java de RAM autant que possible
La solution consultant est de facturer 3 mois pour un driver custom qui se branche sur un autre driver et qui interprètera les requetes pour les ré-exécuter partiellement à la volée afin de simuler le retour en arrière

[Alkhan]

merci tchize_ pour ta réponse !

cela ne fait que confirmer la solution que j'ai envisagé, a savoir refaire les requêtes lors d'un retour arrière.

@+