outOfMemory Java heap size : cache configuration ?

Hibernate version:3.1
Name and version of the database you are using: Oracle 9i

Bonjour,

Je réalise une étude pour la mise en place d'un cache DOM au-dessus d'une base Oracle via hibernate.
Cette base contient des documents XML stockés sous forme de sous arbres.

Voici la table :

Code:

---

1 2 3 4 5 6 7 8 9

CREATE TABLE XDB_ANCHORS ( DOC_ID NUMBER(10), ID NUMBER(10), //id du sous-arbre PARENT_ID NUMBER(10), // id du sous-arbre père POSITION NUMBER(10), //position du sous-arbre dans le sous-arbre parent CONTENT CLOB //XML )

---

Le mapping du CONTENT est fait via un UserType qui à partir du XML cré un DOM.
Hibernate se charge ainsi de cette transformation et le DOM est géré en cache.

Sur des petits fichiers cela marche tres bien, mais sur des gros fichiers, j'obtient un outOfMemory : Java Heap size.

Apres vérification, j'ai constaté que les objets n'etaient jamais libérés pour faire de la place aux nouveaux objets. J'ai également utlisé un profiler pour etre sur de ne garder aucune reference et les seules references sur mes objets sont celle provenant d'hibernate.

J'ai cherche un peu partout mais je ne trouve tjs pas pourquoi les objets ne sont pas evicté automatiquement. J'espère que qq'un pourra m'aider.

merci

William

mapping :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

<?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">   <hibernate-mapping> <class name="com.airbus.hdom.dom.AdocDocumentFragment" table="XDB_ANCHORS" mutable="false"> <cache usage="read-only"/> <composite-id> <key-property name="docId" column="DOC_ID" type="int"/> <key-property name="id" type="int" column="ID"/> <key-property name="evo" type="int" column="EVO"/> </composite-id>   <property name="parentId" column="PARENT_ID"/> <property name="key" column="KEY"/> <property name="isRemoved" column="ISREMOVED"/> <property name="startOffset" column="START_OFFSET"/> <property name="endOffset" column="END_OFFSET"/> <property name="root" type="com.airbus.hdom.util.HibernateTypes.ClobToDomType"> <column name="CONTENT" sql-type="CLOB"/> </property> </class> </hibernate-mapping>

---

Hello

Dans hibernate il existe 2 niveaux de caches.
Sur le premier (niveau session) il est activé par defaut et ne possede aucuns paramétrage. Le deuxième (niveau sessionFactory, commun à l'ensemble des sessions hibernate de l'application) tu as différents paramétrage.
Celui ci dessous (que tu as renseigné dans ton fichier de mapping :

Code:

---

<cache usage="read-only"/>

---

Il indique la stratégie de concurrence par rapport à cette classe entre les différentes transactions (session hibernate).

Tu peux definir ton propre fournisseur cache de second niveau. Je crois que par défaut Hibernate utilise EHCache.
il faudrait que tu verifies la configuration par defaut du fournisseur de cache.
Il est defini dans la propriété

Citation:

---

property name="cache.provider_class"

---

Les paramètres de ton fournisseur de cache te permette de definir les delai d'expiration, le support de stockage des objets dans le cache, etc...

J'espere que cela t'aidera , si tu as des question n'hésite pas!

j'avais fais des essais avec les caches HashtableCache et EhCache
mais je n'avais pas vu qu'il était possible de paramétrer EhCache

donc voici la configuration que j'ai founi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

<ehcache> <diskStore path="java.io.tmpdir"/> <defaultCache maxElementsInMemory="10000" eternal="false" timeToIdleSeconds="30" timeToLiveSeconds="30" overflowToDisk="true" diskPersistent="false" diskExpiryThreadIntervalSeconds="30" /> </ehcache>

---

malgré cela j'ai tjs la meme exception.

Pour remonter les objets, j'utilise une procédure stockées PIPELINED pour optimiser les temps.
Explication :
il est possible de configurer l'application en lui disant qu'on va faire des parcours dans le document XML soit en profondeur, soir en largeur.
Lors d'un parcours en profondeur, si on demande par exemple le root du document, le premier sous-arbre contenant le root est remonté ainsi que les n sous-arbres suivant dans l'ordre SAX. C'est pour cela que j'utilise une procédure PIPELINED : c'est moi qui controle le contenu du resultset.
l'appel de cette procedure stockées se fait comme si c'etait une simple requete SQL, donc j'ai une SQLQuery coté hibernate.

Je me demande si le probleme ne vient pas de la : à chaque fois je remonte une collection, mais lorsqu'il manque de la place, hibernate doit vouloir enlever la collection entiere. Je suppose qu'il ne peut pas enlever 1 objet du cache qui a été remonté dans une collection et comme le parcours est recursif il y a des references sur les collections ce qui les bloque.
Est-il possible d'evincer un objet d'une collection sans avoir à sortir toute la colelction du cache ?

J'ai également activé les traces d'hibernate et je n'ai jamais un appel aux fonctions evict ? je doute que ce soit normal ...

merci

Hello,

Est ce que cette procedure stockée est exécuter dans une seule session Hibernate (implicitement transaction)?

oui

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

private String DOCUMENT_FRAGMENT="SELECT * FROM TABLE (cast ( adocdom.get_children(:aDocID, :aId, :aEvo, :nbchild) as XDB_ANCHORS_TYPE))";   public DocumentFragment getDocumentFragment(int aId, int aDocID, int aEvo) { Session session = HibernateController.currentSession();   SQLQuery q = (SQLQuery)session.createSQLQuery(DOCUMENT_FRAGMENT) .addEntity(AdocDocumentFragment.class) .setInteger("aDocID",aDocID) .setInteger("aId",aId) .setInteger("aEvo",aEvo) .setInteger("nbchild",DomProperties.getIntValue(DomProperties.NB_CHILD)); q.setCacheable(true);   List docFrags = q.list(); return (AdocDocumentFragment)docFrags.get(0); }

---