Persistence de session hibernate lors d'une migration java5 --> java7

Bonjour à tous

Ca fait plus d'une semaine que je suis sur le même problème je ne m'en sors pas.

J'explique : Je dois migrer le site de ma boite sur un serveur sous java7/tomcat7 (auparavant java5/tomcat5.5).
Et depuis, c'est le drame, impossible de se connecter à l'appli, j'ai un CURSOR NOT OPEN sur le chargement d'une liste en LAZY.
Le problème ne se produit qu'avec java7, aucun souci en java5 ou java6.

En fait l'appli récupère un objet stocké en session http, et exécute la jointure quand elle a besoin de l'information.
Mais je pense que la session s'est fermée entre temps, car ça plante avec l'erreur indiquée.
Si je passe la jointure en EAGER, ca ne plante plus, mais cette solution ne convient pas car structurellement ça ne marche pas non plus (pour un tout autre problème).

J'ai essayé beaucoup de choses (montée de version sur driver informix, spring 2.0.1 --> 2.5.6, hibernate), rien n'y fait.
Je compile en java5, mais la compilation en java6 n'a rien amélioré.

J'ai bien le filtre suivant :

Code:

---

1 2 3 4

<filter> <filter-name>hibernateFilter</filter-name> <filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class> </filter>

---

Je sèche. Quelqu'un a-t'il une idée, ou rencontré le même problème ?


Merci à tous ceux qui pourront m'aiguiller

Personnellement, je ne vois pas trop le rapport entre java 5 et java 7 pour ton problème.
Par contre, entre Tomcat 5 et Tomcat 7, il y a eu des changements...

Pour cerner ton problème, essaye de faire tourner ton serveur Tomcat 5 avec un Java 7 et si ça fonctionne, le problème sera clairement dû à la version 7 de Tomcat.

Sinon, dans le principe, c'est un peu normal que la session (hibernate) soit fermée après la réponse, c'est le principe même du filtre.
Donc, tout appel ultérieur à une propriété non initialisée (lazy) plantera, il faut au préalable rattaché l'objet à la session.
Ça me surprend que tu n'es pas eu le problème avant 8O

Merci pour ton retour.
Le problème ne se pose bien qu'avec le java7.

J'ai testé :

* tomcat5/java5 : ok
* tomcat6/java7 : erreur
* tomcat7/java6 : ok
* tomcat7/java7 : erreur

Tu me signales qu'il faut rattacher l'objet à la session, comment faire ? Je pensais que le filtre hibernateFilter s'occupait de ça.
En le désactivant, j'ai exactement la même erreur.

Autre fait étrange, quelques rares fois, ça fonctionne.
Mais si j'arrête et je relance le tomcat, ça ne marche plus (ça fonctionne dans 5% des cas avant un redémarrage)...

Tu devrais faire un merge(entityObject) pour rattacher l'entity.

Bon ca ne marche pas plus, ou j'ai du mal le faire.
J'ai encore modifié pas mal de choses au niveau de la récupération de la session hibernate en passant de this.getSession() à this.getSessionFactory().getCurrentSession() sur toutes mes DAO (et j'en ai un paquet) et pas mieux.
En fait si, j'ai cru avoir résolu mon problème ça a marché jusqu'au 4eme redémarrage du tomcat... Après, c'était mort...

J'avoue que j'en ai marre de ce problème, je vais passer en java6 et basta...

Pour essayer de t'aider un peu plus, peux-tu me décrire le traitement que tu fais, avec les différents cycles s'il y en a ?
Accessoirement, peux-tu poster le code incriminé ?

Citation:

---

Envoyé par Jyhem

impossible de se connecter à l'appli, j'ai un CURSOR NOT OPEN sur le chargement d'une liste en LAZY.

---

On peut avoir la stacktrace de l'erreur? Tu es sur que le driver de base de données que tu utilise est un driver pour la version de JDBC présente dans java 7?
Il y a un bug similare dans openJPA avec informix, https://issues.apache.org/jira/browse/OPENJPA-853 dont le fix a été de faire ceci:

Code:

---

1 2 3

if (isJDBC3 && conn.getHoldability() != ResultSet.HOLD_CURSORS_OVER_COMMIT) { conn.setHoldability(ResultSet.HOLD_CURSORS_OVER_COMMIT);

---

En gros, sur informix, en jdbc3, les curseurs ont par défaut la propriété CLOSE_CURSORS_ON_COMMIT, et je suppose que hibernate ne s'attends pas à ce qu'au premier commit, le curseurs soient fermés. Pour ce qui est de la solution, je n'en trouve que pour les serveur websphere. Il faudrait changer cette valeur par défaut, mais j'ignore comment on le fait sous tomcat7


Edit: il y a aussi la suggestion d'ajouter ça à hibernate

Code:

---

<property name="hibernate.connection.release_mode">on_close</property>

---

ici
https://hibernate.atlassian.net/browse/HHH-2820

Merci pour votre aide :)
Je n'ai pas eu le temps de tester ça aujourd'hui et suis en congé la semaine prochaine.
Je regarde, et reviens vers vous à partir du 28 avril ^^


Edit : J'ai commencé à regarder, la journée n'est pas finie :)

Le driver informix avait déjà été mis à jour (version 10 à version 3.50.JC9) mais cela n'avait rien changé.
J'avais également vu cette histoire de CLOSE_CURSORS_OVER_COMMIT, et j'ai donc désactivé tous commit pour tester (un update était réalisé sur la date de connexion) : même erreur...
Le paramètre on_close ne change rien.
Voici la stacktrace :

CI07-DEV 18-04-2014 17:24:57 || WARN || JDBCExceptionReporter.logExceptions(77) >>> SQL Error: -259, SQLState: 24000
CI07-DEV 18-04-2014 17:24:57 || ERROR || JDBCExceptionReporter.logExceptions(78) >>> Cursor not open.
CI07-DEV 18-04-2014 17:24:57 || INFO || MappingExceptionResolver.resolveException(49) >>> com.adpcl.demat.client.webapp.controller.RouterController@5b281a
CI07-DEV 18-04-2014 17:24:57 || ERROR || MappingExceptionResolver.resolveException(51) >>>
org.hibernate.exception.GenericJDBCException: could not initialize a collection: [com.adpcl.demat.client.model.hibernate.CiAccount.ciOrganization#853]

at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1992)
at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:36)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:565)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1716)
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
at org.hibernate.collection.PersistentBag.iterator(PersistentBag.java:249)
at com.adpcl.demat.client.webapp.controller.utils.GetVarAppliUtils.searchOrganisation(GetVarAppliUtils.java:64) --> c'est ici qu'il exécute la jointure en LAZY
at com.adpcl.demat.client.webapp.InitProfilSession.initProcessSession(InitProfilSession.java:208)
at com.adpcl.demat.client.webapp.interceptor.MyHandlerInterceptor.preHandle(MyHandlerInterceptor.java:65)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:865)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:399)
at org.springframework.security.concurrent.ConcurrentSessionFilter.doFilterHttp(ConcurrentSessionFilter.java:99)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:411)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:411)
at org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:411)
at org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter.doFilterHttp(SecurityContextHolderAwareRequestFilter.java:91)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:411)
at org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:278)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:411)
at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:411)
at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:188)
at org.springframework.security.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:99)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at com.adpcl.demat.client.webapp.controller.utils.Log4jFilter.doFilter(Log4jFilter.java:82)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1852)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

Caused by: java.sql.SQLException: Cursor not open.

at com.informix.util.IfxErrMsg.getSQLException(IfxErrMsg.java:412)
at com.informix.jdbc.IfxSqli.a(IfxSqli.java:3549)
at com.informix.jdbc.IfxSqli.E(IfxSqli.java:3871)
at com.informix.jdbc.IfxSqli.dispatchMsg(IfxSqli.java:2661)
at com.informix.jdbc.IfxSqli.receiveMessage(IfxSqli.java:2577)
at com.informix.jdbc.IfxSqli.j(IfxSqli.java:2248)
at com.informix.jdbc.IfxSqli.getaRow(IfxSqli.java:4589)
at com.informix.jdbc.IfxResultSet.next(IfxResultSet.java:523)
at org.apache.commons.dbcp.DelegatingResultSet.next(DelegatingResultSet.java:207)
at org.apache.commons.dbcp.DelegatingResultSet.next(DelegatingResultSet.java:207)
at org.hibernate.loader.Loader.doQuery(Loader.java:685)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1985)
... 62 more

Caused by: java.sql.SQLException

at com.informix.util.IfxErrMsg.getSQLException(IfxErrMsg.java:412)
at com.informix.jdbc.IfxSqli.E(IfxSqli.java:3876)
... 72 more

Merci encore !

Contre toute attente, j'ai résolu mon bug ! :)

Je met la solution ici même si ça ne servira pas à grand monde :
J'utilise un filtre log4J pour rajouter une info issue de la session dans mes logs (avec MDC). Or dans cette classe, j'utilise un objet en session HTTP pour la récupération du login du membre connecté, objet lié à la session hibernate. Et dans certaines circonstances (je ne sais lesquelles puisque ca marche en java7 localement mais pas sur nos serveurs en java7), ca ne fonctionne pas.
En mettant directement l'information voulue dans une variable String en session, ca fonctionne.

Peut-être le programme essaie-t-il de recharger l'objet via une nouvelle session hibernate, mais sans connexion ouverte à la base.


Merci à tous pour votre aide :)