7 Replies Latest reply on Aug 17, 2007 12:58 PM by klenkes

[CachedConnectionManager] Closing a connection for you

sylobsa Aug 1, 2007 10:54 AM

JBoss4.2.0.GA
jBPM 3.2.0.GA

Hi,
I'm trying to use jBPM 3 in an existing application. I can deploy processes definitions, but when I try to get the process list, I get an error message :
[CachedConnectionManager] Closing a connection for you

Investigating on this error I found that :
- The error occurs in "org.jbpm.persistence.db.DbPersistenceService" when the "Connection getConnection(boolean resolveSession)" method is called
- The connection hasn't been closed because when the "Exception closeConnection()" method is called, the variable mustConnectionBeClosed is set to false

Looking for the reason why "mustConnectionBeClosed", here is the code executed :

In my class :
jbpmContext.getGraphSession().findLatestProcessDefinitions()

In DbPersistenceService :

public GraphSession getGraphSession() {
if (graphSession==null) {
Session session = getSession(); //-- 1
...

public Session getSession() {
if ( (session==null)
&& (getSessionFactory()!=null)
) {
Connection connection = getConnection(false); //-- 2
if (isCurrentSessionEnabled) {
...
} else if (connection!=null) {
log.debug("creating hibernate session with connection "+connection);
session = getSessionFactory().openSession(connection);
mustSessionBeClosed = true;
mustSessionBeFlushed = true;
mustConnectionBeClosed = false; //-- 4
...

public Connection getConnection(boolean resolveSession) {
if (connection==null) {
if (persistenceServiceFactory.getDataSource()!=null) {
try {
log.debug("fetching jdbc connection from datasource");
connection = persistenceServiceFactory.getDataSource().getConnection();
mustConnectionBeClosed = true; //-- 3
...

"mustConnectionBeClosed" is first set to true (//-- 3) getting the connection, then set to false (//-- 4) some lines further, after opening the session.

Is this normal ? How to avoid the error message ? Did I miss something in the configuration ?

Regards
A. ROY

1. Re: [CachedConnectionManager] Closing a connection for you

sylobsa Aug 3, 2007 4:57 AM (in response to sylobsa)

Hi,

There's nobody to help me ?
I don't know Hibernate very well and I don't really know what to do. If I patch jBPM commenting the line marked //--4 on my precedent post (this make the error message disappear), do you think I'll get trouble somewhere else ? Is this the solution ?
Is there another way to avoid the message (modifying configuration) ?

Regards
A. ROY
Actions
2. Re: [CachedConnectionManager] Closing a connection for you

kukeltje Aug 3, 2007 5:03 AM (in response to sylobsa)

Since we've never heard this before, I doubt that patching jBPM is a good way to go. How do you deploy processdefinitions? Through the same connectionpool?
Actions
3. Re: [CachedConnectionManager] Closing a connection for you

sylobsa Aug 3, 2007 6:29 AM (in response to sylobsa)

I use two different configuration files : one for the application and one for jBPM so I suppose I have two connection pools.
The application is configured with a "persistence.xml" file (use of JPA and annotations).
jBPM is configured with hibernate.cfg.xml file and dynamically with a method for some JbpmContext parameters.
When I create a JbpmContext, I systematically call JbpmContext.close() after using it.
I manually edited a processdefinition.xml and I programatically deploy it :

ProcessDefinition processDefinition = ProcessDefinition.parseXmlInputStream(inputStream);
this.jbpmContext.deployProcessDefinition(processDefinition);
this.jbpmContext.close();

This seems to work.

Then, from another part of the application, I try to get the list of processes definitions, so I create a new JbpmContext. It's when the error occurs.
Actions
4. Re: [CachedConnectionManager] Closing a connection for you

estaub Aug 3, 2007 8:04 AM (in response to sylobsa)

I don't have much.
I think you misread DbPersistenceService.getSession().
Reading the first branch in DbPersistenceService.getSession(), it looks like an implementation of session-sharing - the first DbPersistenceService to get a session is responsible for closing it, and others just reuse it.

So I suspect you're barking up the wrong tree in looking for your problem.

When you try to get the process list, what do you do?
Are you on a thread that has already done some JBPM work? Is it possible that you're doubly-initializing something - maybe creating a second JbpmContext without closing the first, or something like that? [I don't know for certain that two JbpmContexts is bad, but I suspect it is - in any event , it's just an example.]

-Ed Staub
Actions
5. Re: [CachedConnectionManager] Closing a connection for you

sylobsa Aug 3, 2007 9:07 AM (in response to sylobsa)

1) I sure steps executed are //--1, //--2, //--3, //--4 because I executed them in debug mode.
2) I'm on a thread that has already done some jBPM work. In fact I have several JbpmConfiguration objects in a HashMap and choose the one I want according to a criteria given by the application, then I create the JbpmContext using : jbpmConfiguration.createJbpmContext(), do my jBPM work and close the JbpmContext. I reviewed my code and I'm sure I call JbpmContext.close() each time jBPM work is done. The problem is that even if I close the context, the connection isn't closed because of the mustConnectionBeClosed variable which is set to false. Why is it set to false whereas seemingly the session should be closed ?
Actions
6. Re: [CachedConnectionManager] Closing a connection for you

estaub Aug 3, 2007 9:40 AM (in response to sylobsa)

>> 1) I sure steps executed are //--1, //--2, //--3, //--4 because I executed them in debug mode.

Sorry, I misread part of your abstract.

It looks to me like the intent is to transfer ownership (responsibility for closing) of the Connection to the Session. So the Service is responsible for closing the Connection as long as there isn't a Session using it.

So... I'd start wondering why the session didn't close the connection. Maybe you didn't close the session the last time you used it?

-Ed Staub
Actions

7. Re: [CachedConnectionManager] Closing a connection for you

klenkes Aug 17, 2007 12:58 PM (in response to sylobsa)

I'm running into the same problem using jbpm-3.1.1, hibernate-3.2.4.SP1 and JBoss 4.0.5.GA.

But I'm using this testcode (with a minimum-workflow consisting of a start and an end node) as CMT bean:

public void showError() {

 log.info("Request received");
 JbpmContext wfContext = wfConfiguration.createJbpmContext();
 ProcessInstance process = wfContext.newProcessInstance("HelloWorld");
 process.signal();

// Session hibernateSession = wfContext.getSession();
 wfContext.close();
 }

As single session bean method called by a servlet.

JBoss closes the JDBC connection

2007-08-17 18:52:20,605 INFO [org.jboss.resource.connectionmanager.CachedConnectionManager] Closing a connection for you. Please close them yourself: org.jboss.resource.adapter.jdbc.WrappedConnection@4f27a3
java.lang.Throwable: STACKTRACE
 at org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection(CachedConnectionManager.java:290)

But then ...

2007-08-17 18:52:20,636 INFO [org.jboss.resource.connectionmanager.TxConnectionManager] throwable from unregister connectionjava.lang.IllegalStateException: Trying to return an unknown connection2! org.jboss.resource.adapter.jdbc.WrappedConnection@4f27a3
 at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:342)
 at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:606)
 at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:266)
 at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:129)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.resource.connectionmanager.CachedConnectionManager.closeConnection(CachedConnectionManager.java:529)
 at org.jboss.resource.connectionmanager.CachedConnectionManager.access$000(CachedConnectionManager.java:63)
 at org.jboss.resource.connectionmanager.CachedConnectionManager$CloseConnectionSynchronization.afterCompletion(CachedConnectionManager.java:607)
 at org.jboss.resource.connectionmanager.TransactionSynchronizer.invokeAfter(TransactionSynchronizer.java:301)
 at org.jboss.resource.connectionmanager.TransactionSynchronizer.afterCompletion(TransactionSynchronizer.java:271)
 at org.jboss.tm.TransactionImpl.doAfterCompletion(TransactionImpl.java:1526)
 at org.jboss.tm.TransactionImpl.completeTransaction(TransactionImpl.java:1198)
 at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:377)
 at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:501)
 at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:361)
 at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
 at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
 at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
 at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
 at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648)
 at org.jboss.ejb.Container.invoke(Container.java:954)
 at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:430)
 at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
 at $Proxy66.showError(Unknown Source)
 at de.telefonica.lich12.jbpmtest.TriggerServlet.doGet(TriggerServlet.java:101)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)

Does anybody know why JBoss is closing the connection just a few milliseconds before JBPM tries it itself?

I'm using a clean JBoss 4.0.5.GA with hibernate tree cache as MXBean and JBPM and Hibernate as POJO inside the EAR file (consisting of the small session bean above and the servlet calling that session bean).

Go to original post