I have the following issue: one Weblogic application calls another WL application as part of one global JTA transaction, each use Hibernate to persist information to the database. Everything works fine up (including calls to flush the session prior to this point) until the .closeConnection() is called in BatcherImpl when the transaction is ready to commit. When JDBCExceptionReporter.logWarnings() is called the stack trace below results.
I noticed in the source that a catch block was added specifically for WL per the following bug report:
http://opensource.atlassian.com/project ... wse/HB-360. It seems like I have to take it one step further and completely comment out the JDBCExceptionReporter.logWarnings() call in order for the transaction to commit. Or I have to move all the open source jars (commons-logging.jar, hibernate.jar, etc.) to the system classpath of the server. The latter is an unacceptable solution for us because IT wouldn't be too happy about mucking with the server classpath.
First, I am wondering what could be the issue here because each application has it's own copy of commons-logging and WL isolates them in their own classloader. Frankly, I really don't understand how this happens only in the .closeConnection() because it seems to log fine everywhere else commons-logging is at.
Second, if I choose to comment out the .logWarnings() am I really missing that much because I chose to flush the session in the application so therefore I would of already knew if there was some sort of database issue. In other words, this might be a workable solution despite how dodgy is sounds. What does .logWarnings() really do at this point anyway if you already flushed the session?
Well again, any guidance would be greatly appreciated. I'm getting a lot of crap over this enough where management FUD is starting to say things like, "...let's use EJB instead" -- YIKES!!
Debugging of classloader
=========================
##### closeConnection classloader: weblogic.utils.classloaders.GenericClassLoader@838745 finder: weblogic.utils.classloaders.MultiClassFinder@b5845c annotation: Claim@
##### closeConnection Log classloader: weblogic.utils.classloaders.GenericClassLoader@838745 finder: weblogic.utils.classloaders.MultiClassFinder@b5845c annotation: Claim@
##### closeConnection Thread classloader: weblogic.utils.classloaders.GenericClassLoader@5ef7f2 finder: weblogic.utils.classloaders.MultiClassFinder@110ba8b annotation: Test@1_0
##### closeConnection classloader: weblogic.utils.classloaders.GenericClassLoader@e852e8 finder: weblogic.utils.classloaders.MultiClassFinder@1472541 annotation: Test@
##### closeConnection Log classloader: weblogic.utils.classloaders.GenericClassLoader@e852e8 finder: weblogic.utils.classloaders.MultiClassFinder@1472541 annotation: Test@
##### closeConnection Thread classloader: weblogic.utils.classloaders.GenericClassLoader@5ef7f2 finder: weblogic.utils.classloaders.MultiClassFinder@110ba8b annotation: Test@1_0
Source that generates above debug:
Code:
public void closeConnection(Connection conn) throws HibernateException {
try {
if ( !conn.isClosed() ) {
try {
System.out.println("##### closeConnection classloader: " + this.getClass().getClassLoader());
System.out.println("##### closeConnection Log classloader: " + log.getClass().getClassLoader());
System.out.println("##### closeConnection Thread classloader: " + Thread.currentThread().getContextClassLoader());
//JDBCExceptionReporter.logWarnings( conn.getWarnings() );
}
//catch (SQLException sqle) {
//workaround for WebLogic
//log.debug("could not log warnings", sqle);
//}
//catch (Throwable t) {
// catch logger exceptions from commons logging
//log.warn("could not log warnings", t);
//}
finally {
conn.clearWarnings();
}
}
factory.getConnectionProvider().closeConnection(conn);
}
catch (SQLException sqle) {
throw new JDBCException("Cannot close connection", sqle);
}
}
Stack Trace
============================
<Apr 9, 2005 1:41:17 PM PDT> <Error> <EJB> <BEA-010026> <Exception occurred during commit of transaction Name=[EJB com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)],Xid=BEA1-0239DF9DAD1BB9F1486B(27170472),Status=Rolled back. [Reason=java.lang.ExceptionInInitializerError],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=17,seconds left=60,XAServerResourceInfo[clmPool]=(ServerResourceInfo[clmPool]=(state=rolledback,assigned=cgServer_ls97241),xar=clmPool,re-Registered = false),XAServerResourceInfo[JMS_cgJMSStore]=(ServerResourceInfo[JMS_cgJMSStore]=(state=rolledback,assigned=cgServer_ls97241),xar=JMS_cgJMSStore,re-Registered = false),SCInfo[sa-wlimtch-pc-sp3-ls97241+cgServer_ls97241]=(state=rolledback),properties=({weblogic.transaction.name=[EJB com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)]}),local properties=({}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=cgServer_ls97241+172.24.171.49:7501+sa-wlimtch-pc-sp3-ls97241+t3+, XAResources={},NonXAResources={})],CoordinatorURL=cgServer_ls97241+172.24.171.49:7501+sa-wlimtch-pc-sp3-ls97241+t3+): java.lang.ExceptionInInitializerError
at net.sf.hibernate.impl.BatcherImpl.closeConnection(BatcherImpl.java:297)
at net.sf.hibernate.impl.SessionImpl.disconnect(SessionImpl.java:3352)
at net.sf.hibernate.impl.SessionImpl.close(SessionImpl.java:576)
at org.springframework.orm.hibernate.SessionFactoryUtils.doClose(SessionFactoryUtils.java:734)
at org.springframework.orm.hibernate.SessionFactoryUtils.closeSessionOrRegisterDeferredClose(SessionFactoryUtils.java:723)
at org.springframework.orm.hibernate.SessionFactoryUtils.access$300(SessionFactoryUtils.java:89)
at org.springframework.orm.hibernate.SessionFactoryUtils$SpringSessionSynchronization.beforeCompletion(SessionFactoryUtils.java:863)
at org.springframework.orm.hibernate.SessionFactoryUtils$JtaSessionSynchronization.beforeCompletion(SessionFactoryUtils.java:960)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1010)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:115)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:1184)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1910)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:273)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:244)
at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:299)
at weblogic.ejb20.internal.StatelessEJBObject.postInvoke(StatelessEJBObject.java:140)
at com.bea.wlw.runtime.core.bean.SyncDispatcher_k1mrl8_EOImpl.invoke(SyncDispatcher_k1mrl8_EOImpl.java:110)
at com.bea.wlw.runtime.core.dispatcher.Dispatcher.remoteDispatch(Dispatcher.java:161)
at com.bea.wlw.runtime.core.dispatcher.Dispatcher.dispatch(Dispatcher.java:49)
at com.bea.wlw.runtime.core.dispatcher.HttpServerHelper.executePostRequest(HttpServerHelper.java:713)
at com.bea.wlw.runtime.core.dispatcher.HttpServer.doPost(HttpServer.java:49)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:996)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:419)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:315)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6456)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3661)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2630)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.))
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:549)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at net.sf.hibernate.util.JDBCExceptionReporter.<clinit>(JDBCExceptionReporter.java:12)
... 33 more
Hibernate version:
2.1.6
Mapping documents:
Code between sessionFactory.openSession() and session.close():
Full stack trace of any exception that occurs:
Name and version of the database you are using:
The generated SQL (show_sql=true):
Debug level Hibernate log excerpt:
Login
FAQ
Search
