August 2014 - Topia-devel - mailman.cloud.codelutin.com

Pourquoi les getters ne renverraient pas une collection vide ?
by Brendan Le Ny 24 Nov '14

24 Nov '14

Actuellement, une propriété avec une multiplicité renvoie une collection null si on appelle le getter, pourquoi ne pas initialiser cette collection en lazy (on le fait bien dans le add) ? Voire même, pourquoi pas interdire d'appeler le setter avec null (sauf si Hibernate l'impose) ? Il me semblait y avoir une raison mais elle ne me revient plus. -- Brendan Le Ny, Code Lutin bleny(a)codelutin.com (+33) 02 40 50 29 28

4 4

Fetch mathematics
by Eric Chatellier 26 Aug '14

26 Aug '14

Bonjour, Pour faire un retours sur la performance (ou non performance des fetch), voici quelque stats sur un cas rapide sur PostgresSQL, mais très lent sur Sql Server. Le problème de lenteur n'est pas le point ici, mais plutot le volume de données qui transit. Pour la volumétrie de la requete, on a: - 1 Mail (23 champs) - 4 Pièces jointes (9 champs) - 56 Ligne d'historique (7 champs) - 11 autres entité de cardinalité 1 (EtatAttente, DemandStatus...) La requete executée est la suivante: http://forge.codelutin.com/issues/5655#note-3 Elle retourne environ 224 lignes (soit le produit cartésien de 1 * 4 * 56) L'ensemble des champs représente 131 colonne. Soit un ResultSet composé de 29344 élément. Donc 29344 pour afficher un seul élément. À titre de comparaison, la même fonctionnalité en 3 requêtes aurait retourné 1 * 115 = 115 (email + relation 0..1 avec fetch) 4 * 9 = 36 (attachments) 56 * 7 = 392 (historique) Soit un result set de 543 éléments, mais en 3 requetes. Le produit cartésien augmente beaucoup la taille donc je me demande si c'est si performant que ca, ou que cela doit être nuancé par la volumétries des données. Ne faudrait-il pas laisser les fetch pour les relations (0..1) et effectuer d'autres requetes pour les autres relations (2..*) ? -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

3 2

Pool C3p0 non fermé
by Eric Chatellier 25 Aug '14

25 Aug '14

Bonjoir, Actuellement, lors d'un hot redeploy dans tomcat, le pool c3p0 semble garder les connexions ouvertes. Voici les traces au redémarrage: rave: The web application [/xxx] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->z8kflt90l3muy4yyzl36|6c187ab5]-AdminTaskTimer] but has failed to stop it. This is very likely to create a memory leak. févr. 19, 2014 10:28:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads Grave: The web application [/xxx] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->z8kflt90l3muy4yyzl36|6c187ab5]-HelperThread-#0] but has failed to stop it. This is very likely to create a memory leak. févr. 19, 2014 10:28:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads Grave: The web application [/xxx] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->z8kflt90l3muy4yyzl36|6c187ab5]-HelperThread-#1] but has failed to stop it. This is very likely to create a memory leak. févr. 19, 2014 10:28:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads Grave: The web application [/xxx] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->z8kflt90l3muy4yyzl36|6c187ab5]-HelperThread-#2] but has failed to stop it. This is very likely to create a memory leak. févr. 19, 2014 10:28:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads Grave: The web application [/xxx] appears to have started a thread named [H2 File Lock Watchdog /tmp/xxx/h2data-web.lock.db] but has failed to stop it. This is very likely to create a memory leak. févr. 19, 2014 10:28:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads Grave: The web application [/xxx] appears to have started a thread named [H2 Log Writer H2DATA-WEB] but has failed to stop it. This is very likely to create a memory leak. févr. 19, 2014 10:28:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads Grave: The web application [/xxx] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->z8kflt90l3muy4yyzl36|7dfbfca7]-AdminTaskTimer] but has failed to stop it. This is very likely to create a memory leak. févr. 19, 2014 10:28:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads Grave: The web application [/xxx] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->z8kflt90l3muy4yyzl36|7dfbfca7]-HelperThread-#0] but has failed to stop it. This is very likely to create a memory leak. févr. 19, 2014 10:28:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads Grave: The web application [/xxx] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->z8kflt90l3muy4yyzl36|7dfbfca7]-HelperThread-#1] but has failed to stop it. This is very likely to create a memory leak. févr. 19, 2014 10:28:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads Grave: The web application [/xxx] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->z8kflt90l3muy4yyzl36|7dfbfca7]-HelperThread-#2] but has failed to stop it. This is very likely to create a memory leak. 22:28:36 [ContainerBackgroundProcessor[StandardEngine[Catalina]]] WARN ActiveManagementCoordinator:68 - A C3P0Registry mbean is already registered. This probably means that an application using c3p0 was undeployed, but not all PooledDataSources were closed prior to undeployment. This may lead to resource leaks over time. Please take care to close all PooledDataSources. J'ai trouvé un gros gros hack qui fonctionne: http://stackoverflow.com/a/7472386 ce qui semble bien démontrer qu'il y a un problème quelque part avec Topia/Hibernate (c3p0?). To be continued... -- Éric Chatellier

3 3