RE: Trying to return an unknown connection2!
Wondering if any work has been done on this. I am now getting the same error, and wondering if I could test the changes. -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 12:09 PM To: OJB Users List Subject: Re: Trying to return an unknown connection2! For managed enviroment this seems to be better. ;-) Is it a difference or disadvantage for unmanaged enviroments? of course it's different in non managed environments, because we only can close a connection after PB.commit/abortTx when using PB-tx. We have to take of side-effects in non-managed environments when decouple connectionManager.isInLocalTx from PB. Of course I'm willing to test a fix. I'm currently a litte bit bussy too so impementing a fix on our own maybe difficult but I'll check it. Great! I will contact you when the enhancement is in CVS. Please don't hesitate to contact me if you have the feeling that I forgot it ;-) regards, Armin Guido Beutler wrote: Hi Armin, Armin Waibel wrote: Hi Guido, we can try to release the used connection on PB.close() call instead of Synchronization#beforeCompleation. For managed enviroment this seems to be better. ;-) Is it a difference or disadvantage for unmanaged enviroments? In PBFSyncImpl line 227 the close() method of PBImpl is overridden. If we are in local-tx we don't really close the used PB handle and thus do not release the used connection (it's done in #beforeCompleation). To do so we have to make PB.isInTransaction method independed from ConnectionManager.isInLocalTransaction method. After that we can release the used connection (via connectionManager) in PBSyncImpl.close method and keep PBSyncImpl still in PB-tx. Sounds like I have to take a look on it to understand what's to change. Currently I'm busy with other OJB stuff, but I will try this ASAP. Are you willing to test my changes or do you want to start this refactoring by your own? Of course I'm willing to test a fix. I'm currently a litte bit bussy too so impementing a fix on our own maybe difficult but I'll check it. thanks for the help and best regards, Guido regards, Armin Guido Beutler wrote: Hi Armin, sorry for the delay! Because nobody else had an answer I spent some time to get closer to the problem. After that I posted my question at jboss. Here's the thread: http://www.jboss.org/index.html?module=bbop=viewtopict=49041 I don't know if I am allowed to repost the answer here (copyrights etc. ) Please use the link above. I'm curious about the replies here. best regards, Guido Armin Waibel wrote: Hi Guido, Any ideas what's going on there? I only answer to say No, I don't have a clue. I assume (maybe I'm completely wrong ;-)) that JBoss has problems in handling the connections/DataSources associated with the running tx in a proper way. Your direct connection instance will be associated with the suspended tx, within the new tx OJB lookup a new connection, do all work and close the connection. It seems that the used connection is not vaild in jboss TxConnectionManager...bla, bla Reached the line count for a do my best answer ;-) regards, Armin Guido Beutler wrote: Hello, I've got a strange problem with RC6 at JBoss 3.2.3. I've got a statefull and a stateless session bean. The stateless session bean contains all OJB stuff. The statefull facade accesses some tables via JDBC directly. That stateless session OJB bean has transaction attribute RequiresNew. The facade runs with Required. Both ejb's are container managed. If a method allocates a JDBC Connection from data source and then access the OJB EJB the following exception is thrown. java.lang.IllegalStateException: Trying to return an unknown connection2! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unreg isterConnection(CachedConnectionManager.java:330) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnect ionEventListener.connectionClosed(TxConnectionManager.java:539) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.close Handle(BaseWrapperManagedConnection.java:296) at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedCon nection.java:117) at org.apache.ojb.broker.util.WrappedConnection.close(WrappedConnecti on.java:124) at org.apache.ojb.broker.util.pooling.ByPassConnection.close(ByPassCo nnection.java:64) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.re leaseConnection(ConnectionFactoryAbstractImpl.java:79) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseCon nection(ConnectionManagerImpl.java:286) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$Persis tenceBrokerSyncImpl.beforeCompletion(PersistenceBrokerFactorySyncI mpl.jav a:177
Re: Trying to return an unknown connection2!
Hi Andrew, Clute, Andrew wrote: Wondering if any work has been done on this. I am now getting the same error, and wondering if I could test the changes. Did you try latest from CVS? I checked in the changes a few days ago. The optimations only made for the PB-api. Do you have problems with PB-api or ODMG-api? regards, Armin -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 12:09 PM To: OJB Users List Subject: Re: Trying to return an unknown connection2! For managed enviroment this seems to be better. ;-) Is it a difference or disadvantage for unmanaged enviroments? of course it's different in non managed environments, because we only can close a connection after PB.commit/abortTx when using PB-tx. We have to take of side-effects in non-managed environments when decouple connectionManager.isInLocalTx from PB. Of course I'm willing to test a fix. I'm currently a litte bit bussy too so impementing a fix on our own maybe difficult but I'll check it. Great! I will contact you when the enhancement is in CVS. Please don't hesitate to contact me if you have the feeling that I forgot it ;-) regards, Armin Guido Beutler wrote: Hi Armin, Armin Waibel wrote: Hi Guido, we can try to release the used connection on PB.close() call instead of Synchronization#beforeCompleation. For managed enviroment this seems to be better. ;-) Is it a difference or disadvantage for unmanaged enviroments? In PBFSyncImpl line 227 the close() method of PBImpl is overridden. If we are in local-tx we don't really close the used PB handle and thus do not release the used connection (it's done in #beforeCompleation). To do so we have to make PB.isInTransaction method independed from ConnectionManager.isInLocalTransaction method. After that we can release the used connection (via connectionManager) in PBSyncImpl.close method and keep PBSyncImpl still in PB-tx. Sounds like I have to take a look on it to understand what's to change. Currently I'm busy with other OJB stuff, but I will try this ASAP. Are you willing to test my changes or do you want to start this refactoring by your own? Of course I'm willing to test a fix. I'm currently a litte bit bussy too so impementing a fix on our own maybe difficult but I'll check it. thanks for the help and best regards, Guido regards, Armin Guido Beutler wrote: Hi Armin, sorry for the delay! Because nobody else had an answer I spent some time to get closer to the problem. After that I posted my question at jboss. Here's the thread: http://www.jboss.org/index.html?module=bbop=viewtopict=49041 I don't know if I am allowed to repost the answer here (copyrights etc. ) Please use the link above. I'm curious about the replies here. best regards, Guido Armin Waibel wrote: Hi Guido, Any ideas what's going on there? I only answer to say No, I don't have a clue. I assume (maybe I'm completely wrong ;-)) that JBoss has problems in handling the connections/DataSources associated with the running tx in a proper way. Your direct connection instance will be associated with the suspended tx, within the new tx OJB lookup a new connection, do all work and close the connection. It seems that the used connection is not vaild in jboss TxConnectionManager...bla, bla Reached the line count for a do my best answer ;-) regards, Armin Guido Beutler wrote: Hello, I've got a strange problem with RC6 at JBoss 3.2.3. I've got a statefull and a stateless session bean. The stateless session bean contains all OJB stuff. The statefull facade accesses some tables via JDBC directly. That stateless session OJB bean has transaction attribute RequiresNew. The facade runs with Required. Both ejb's are container managed. If a method allocates a JDBC Connection from data source and then access the OJB EJB the following exception is thrown. java.lang.IllegalStateException: Trying to return an unknown connection2! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unreg isterConnection(CachedConnectionManager.java:330) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnect ionEventListener.connectionClosed(TxConnectionManager.java:539) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.close Handle(BaseWrapperManagedConnection.java:296) at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedCon nection.java:117) at org.apache.ojb.broker.util.WrappedConnection.close(WrappedConnecti on.java:124) at org.apache.ojb.broker.util.pooling.ByPassConnection.close(ByPassCo nnection.java:64) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.re leaseConnection(ConnectionFactoryAbstractImpl.java:79) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseCon nection(ConnectionManagerImpl.java:286) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$Persis
RE: Trying to return an unknown connection2!
You know, I have a bad habit of asking questions for before looking at the CVS log. ;) I have downloaded the new changes, and they are working perfectly. I am using PB-Api. My method that does non-CMT work, and also calls EJB's that have CMT is working properly. Thanks -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 10:42 AM To: OJB Users List Subject: Re: Trying to return an unknown connection2! Hi Andrew, Clute, Andrew wrote: Wondering if any work has been done on this. I am now getting the same error, and wondering if I could test the changes. Did you try latest from CVS? I checked in the changes a few days ago. The optimations only made for the PB-api. Do you have problems with PB-api or ODMG-api? regards, Armin -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 12:09 PM To: OJB Users List Subject: Re: Trying to return an unknown connection2! For managed enviroment this seems to be better. ;-) Is it a difference or disadvantage for unmanaged enviroments? of course it's different in non managed environments, because we only can close a connection after PB.commit/abortTx when using PB-tx. We have to take of side-effects in non-managed environments when decouple connectionManager.isInLocalTx from PB. Of course I'm willing to test a fix. I'm currently a litte bit bussy too so impementing a fix on our own maybe difficult but I'll check it. Great! I will contact you when the enhancement is in CVS. Please don't hesitate to contact me if you have the feeling that I forgot it ;-) regards, Armin Guido Beutler wrote: Hi Armin, Armin Waibel wrote: Hi Guido, we can try to release the used connection on PB.close() call instead of Synchronization#beforeCompleation. For managed enviroment this seems to be better. ;-) Is it a difference or disadvantage for unmanaged enviroments? In PBFSyncImpl line 227 the close() method of PBImpl is overridden. If we are in local-tx we don't really close the used PB handle and thus do not release the used connection (it's done in #beforeCompleation). To do so we have to make PB.isInTransaction method independed from ConnectionManager.isInLocalTransaction method. After that we can release the used connection (via connectionManager) in PBSyncImpl.close method and keep PBSyncImpl still in PB-tx. Sounds like I have to take a look on it to understand what's to change. Currently I'm busy with other OJB stuff, but I will try this ASAP. Are you willing to test my changes or do you want to start this refactoring by your own? Of course I'm willing to test a fix. I'm currently a litte bit bussy too so impementing a fix on our own maybe difficult but I'll check it. thanks for the help and best regards, Guido regards, Armin Guido Beutler wrote: Hi Armin, sorry for the delay! Because nobody else had an answer I spent some time to get closer to the problem. After that I posted my question at jboss. Here's the thread: http://www.jboss.org/index.html?module=bbop=viewtopict=49041 I don't know if I am allowed to repost the answer here (copyrights etc. ) Please use the link above. I'm curious about the replies here. best regards, Guido Armin Waibel wrote: Hi Guido, Any ideas what's going on there? I only answer to say No, I don't have a clue. I assume (maybe I'm completely wrong ;-)) that JBoss has problems in handling the connections/DataSources associated with the running tx in a proper way. Your direct connection instance will be associated with the suspended tx, within the new tx OJB lookup a new connection, do all work and close the connection. It seems that the used connection is not vaild in jboss TxConnectionManager...bla, bla Reached the line count for a do my best answer ;-) regards, Armin Guido Beutler wrote: Hello, I've got a strange problem with RC6 at JBoss 3.2.3. I've got a statefull and a stateless session bean. The stateless session bean contains all OJB stuff. The statefull facade accesses some tables via JDBC directly. That stateless session OJB bean has transaction attribute RequiresNew. The facade runs with Required. Both ejb's are container managed. If a method allocates a JDBC Connection from data source and then access the OJB EJB the following exception is thrown. java.lang.IllegalStateException: Trying to return an unknown connection2! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unreg isterConnection(CachedConnectionManager.java:330) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnect ionEventListener.connectionClosed(TxConnectionManager.java:539) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.close Handle(BaseWrapperManagedConnection.java:296
Re: Trying to return an unknown connection2!
Hi again, Clute, Andrew wrote: You know, I have a bad habit of asking questions for before looking at the CVS log. ;) no problem, nobody is perfect and I love to write get latest from CVS, it's fixed ;-) I have downloaded the new changes, and they are working perfectly. I am using PB-Api. My method that does non-CMT work, and also calls EJB's that have CMT is working properly. thanks for testing! regards, Armin Thanks -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 10:42 AM To: OJB Users List Subject: Re: Trying to return an unknown connection2! Hi Andrew, Clute, Andrew wrote: Wondering if any work has been done on this. I am now getting the same error, and wondering if I could test the changes. Did you try latest from CVS? I checked in the changes a few days ago. The optimations only made for the PB-api. Do you have problems with PB-api or ODMG-api? regards, Armin -Andrew -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 12:09 PM To: OJB Users List Subject: Re: Trying to return an unknown connection2! For managed enviroment this seems to be better. ;-) Is it a difference or disadvantage for unmanaged enviroments? of course it's different in non managed environments, because we only can close a connection after PB.commit/abortTx when using PB-tx. We have to take of side-effects in non-managed environments when decouple connectionManager.isInLocalTx from PB. Of course I'm willing to test a fix. I'm currently a litte bit bussy too so impementing a fix on our own maybe difficult but I'll check it. Great! I will contact you when the enhancement is in CVS. Please don't hesitate to contact me if you have the feeling that I forgot it ;-) regards, Armin Guido Beutler wrote: Hi Armin, Armin Waibel wrote: Hi Guido, we can try to release the used connection on PB.close() call instead of Synchronization#beforeCompleation. For managed enviroment this seems to be better. ;-) Is it a difference or disadvantage for unmanaged enviroments? In PBFSyncImpl line 227 the close() method of PBImpl is overridden. If we are in local-tx we don't really close the used PB handle and thus do not release the used connection (it's done in #beforeCompleation). To do so we have to make PB.isInTransaction method independed from ConnectionManager.isInLocalTransaction method. After that we can release the used connection (via connectionManager) in PBSyncImpl.close method and keep PBSyncImpl still in PB-tx. Sounds like I have to take a look on it to understand what's to change. Currently I'm busy with other OJB stuff, but I will try this ASAP. Are you willing to test my changes or do you want to start this refactoring by your own? Of course I'm willing to test a fix. I'm currently a litte bit bussy too so impementing a fix on our own maybe difficult but I'll check it. thanks for the help and best regards, Guido regards, Armin Guido Beutler wrote: Hi Armin, sorry for the delay! Because nobody else had an answer I spent some time to get closer to the problem. After that I posted my question at jboss. Here's the thread: http://www.jboss.org/index.html?module=bbop=viewtopict=49041 I don't know if I am allowed to repost the answer here (copyrights etc. ) Please use the link above. I'm curious about the replies here. best regards, Guido Armin Waibel wrote: Hi Guido, Any ideas what's going on there? I only answer to say No, I don't have a clue. I assume (maybe I'm completely wrong ;-)) that JBoss has problems in handling the connections/DataSources associated with the running tx in a proper way. Your direct connection instance will be associated with the suspended tx, within the new tx OJB lookup a new connection, do all work and close the connection. It seems that the used connection is not vaild in jboss TxConnectionManager...bla, bla Reached the line count for a do my best answer ;-) regards, Armin Guido Beutler wrote: Hello, I've got a strange problem with RC6 at JBoss 3.2.3. I've got a statefull and a stateless session bean. The stateless session bean contains all OJB stuff. The statefull facade accesses some tables via JDBC directly. That stateless session OJB bean has transaction attribute RequiresNew. The facade runs with Required. Both ejb's are container managed. If a method allocates a JDBC Connection from data source and then access the OJB EJB the following exception is thrown. java.lang.IllegalStateException: Trying to return an unknown connection2! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unreg isterConnection(CachedConnectionManager.java:330) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnect ionEventListener.connectionClosed(TxConnectionManager.java:539) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.close
Re: Trying to return an unknown connection2!
Hi Armin, sorry for the delay! Because nobody else had an answer I spent some time to get closer to the problem. After that I posted my question at jboss. Here's the thread: http://www.jboss.org/index.html?module=bbop=viewtopict=49041 I don't know if I am allowed to repost the answer here (copyrights etc. ) Please use the link above. I'm curious about the replies here. best regards, Guido Armin Waibel wrote: Hi Guido, Any ideas what's going on there? I only answer to say No, I don't have a clue. I assume (maybe I'm completely wrong ;-)) that JBoss has problems in handling the connections/DataSources associated with the running tx in a proper way. Your direct connection instance will be associated with the suspended tx, within the new tx OJB lookup a new connection, do all work and close the connection. It seems that the used connection is not vaild in jboss TxConnectionManager...bla, bla Reached the line count for a do my best answer ;-) regards, Armin Guido Beutler wrote: Hello, I've got a strange problem with RC6 at JBoss 3.2.3. I've got a statefull and a stateless session bean. The stateless session bean contains all OJB stuff. The statefull facade accesses some tables via JDBC directly. That stateless session OJB bean has transaction attribute RequiresNew. The facade runs with Required. Both ejb's are container managed. If a method allocates a JDBC Connection from data source and then access the OJB EJB the following exception is thrown. java.lang.IllegalStateException: Trying to return an unknown connection2! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:330) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:539) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:296) at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:117) at org.apache.ojb.broker.util.WrappedConnection.close(WrappedConnection.java:124) at org.apache.ojb.broker.util.pooling.ByPassConnection.close(ByPassConnection.java:64) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.releaseConnection(ConnectionFactoryAbstractImpl.java:79) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java:286) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion(PersistenceBrokerFactorySyncImpl.jav a:177) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion(PersistenceBrokerFactorySyncImpl.java:329) at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1308) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:398) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:325) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331) at org.jboss.ejb.Container.invoke(Container.java:700) 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:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:101) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45) at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:100) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85) I've got 2 workarounds. 1) If I change RequiresNew at the OJB EJB into Required the problem disappears. 2) If the facade does no access a JDBC connection the problem disappears too. Any ideas what's going on there? best regards, Guido
Re: Trying to return an unknown connection2!
Hi Guido, we can try to release the used connection on PB.close() call instead of Synchronization#beforeCompleation. In PBFSyncImpl line 227 the close() method of PBImpl is overridden. If we are in local-tx we don't really close the used PB handle and thus do not release the used connection (it's done in #beforeCompleation). To do so we have to make PB.isInTransaction method independed from ConnectionManager.isInLocalTransaction method. After that we can release the used connection (via connectionManager) in PBSyncImpl.close method and keep PBSyncImpl still in PB-tx. Currently I'm busy with other OJB stuff, but I will try this ASAP. Are you willing to test my changes or do you want to start this refactoring by your own? regards, Armin Guido Beutler wrote: Hi Armin, sorry for the delay! Because nobody else had an answer I spent some time to get closer to the problem. After that I posted my question at jboss. Here's the thread: http://www.jboss.org/index.html?module=bbop=viewtopict=49041 I don't know if I am allowed to repost the answer here (copyrights etc. ) Please use the link above. I'm curious about the replies here. best regards, Guido Armin Waibel wrote: Hi Guido, Any ideas what's going on there? I only answer to say No, I don't have a clue. I assume (maybe I'm completely wrong ;-)) that JBoss has problems in handling the connections/DataSources associated with the running tx in a proper way. Your direct connection instance will be associated with the suspended tx, within the new tx OJB lookup a new connection, do all work and close the connection. It seems that the used connection is not vaild in jboss TxConnectionManager...bla, bla Reached the line count for a do my best answer ;-) regards, Armin Guido Beutler wrote: Hello, I've got a strange problem with RC6 at JBoss 3.2.3. I've got a statefull and a stateless session bean. The stateless session bean contains all OJB stuff. The statefull facade accesses some tables via JDBC directly. That stateless session OJB bean has transaction attribute RequiresNew. The facade runs with Required. Both ejb's are container managed. If a method allocates a JDBC Connection from data source and then access the OJB EJB the following exception is thrown. java.lang.IllegalStateException: Trying to return an unknown connection2! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:330) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:539) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:296) at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:117) at org.apache.ojb.broker.util.WrappedConnection.close(WrappedConnection.java:124) at org.apache.ojb.broker.util.pooling.ByPassConnection.close(ByPassConnection.java:64) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.releaseConnection(ConnectionFactoryAbstractImpl.java:79) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java:286) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion(PersistenceBrokerFactorySyncImpl.jav a:177) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion(PersistenceBrokerFactorySyncImpl.java:329) at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1308) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:398) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:325) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331) at org.jboss.ejb.Container.invoke(Container.java:700) 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:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
Re: Trying to return an unknown connection2!
Hi Armin, Armin Waibel wrote: Hi Guido, we can try to release the used connection on PB.close() call instead of Synchronization#beforeCompleation. For managed enviroment this seems to be better. ;-) Is it a difference or disadvantage for unmanaged enviroments? In PBFSyncImpl line 227 the close() method of PBImpl is overridden. If we are in local-tx we don't really close the used PB handle and thus do not release the used connection (it's done in #beforeCompleation). To do so we have to make PB.isInTransaction method independed from ConnectionManager.isInLocalTransaction method. After that we can release the used connection (via connectionManager) in PBSyncImpl.close method and keep PBSyncImpl still in PB-tx. Sounds like I have to take a look on it to understand what's to change. Currently I'm busy with other OJB stuff, but I will try this ASAP. Are you willing to test my changes or do you want to start this refactoring by your own? Of course I'm willing to test a fix. I'm currently a litte bit bussy too so impementing a fix on our own maybe difficult but I'll check it. thanks for the help and best regards, Guido regards, Armin Guido Beutler wrote: Hi Armin, sorry for the delay! Because nobody else had an answer I spent some time to get closer to the problem. After that I posted my question at jboss. Here's the thread: http://www.jboss.org/index.html?module=bbop=viewtopict=49041 I don't know if I am allowed to repost the answer here (copyrights etc. ) Please use the link above. I'm curious about the replies here. best regards, Guido Armin Waibel wrote: Hi Guido, Any ideas what's going on there? I only answer to say No, I don't have a clue. I assume (maybe I'm completely wrong ;-)) that JBoss has problems in handling the connections/DataSources associated with the running tx in a proper way. Your direct connection instance will be associated with the suspended tx, within the new tx OJB lookup a new connection, do all work and close the connection. It seems that the used connection is not vaild in jboss TxConnectionManager...bla, bla Reached the line count for a do my best answer ;-) regards, Armin Guido Beutler wrote: Hello, I've got a strange problem with RC6 at JBoss 3.2.3. I've got a statefull and a stateless session bean. The stateless session bean contains all OJB stuff. The statefull facade accesses some tables via JDBC directly. That stateless session OJB bean has transaction attribute RequiresNew. The facade runs with Required. Both ejb's are container managed. If a method allocates a JDBC Connection from data source and then access the OJB EJB the following exception is thrown. java.lang.IllegalStateException: Trying to return an unknown connection2! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:330) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:539) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:296) at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:117) at org.apache.ojb.broker.util.WrappedConnection.close(WrappedConnection.java:124) at org.apache.ojb.broker.util.pooling.ByPassConnection.close(ByPassConnection.java:64) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.releaseConnection(ConnectionFactoryAbstractImpl.java:79) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java:286) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion(PersistenceBrokerFactorySyncImpl.jav a:177) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion(PersistenceBrokerFactorySyncImpl.java:329) at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1308) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:398) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:325) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331) at org.jboss.ejb.Container.invoke(Container.java:700) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: Trying to return an unknown connection2!
For managed enviroment this seems to be better. ;-) Is it a difference or disadvantage for unmanaged enviroments? of course it's different in non managed environments, because we only can close a connection after PB.commit/abortTx when using PB-tx. We have to take of side-effects in non-managed environments when decouple connectionManager.isInLocalTx from PB. Of course I'm willing to test a fix. I'm currently a litte bit bussy too so impementing a fix on our own maybe difficult but I'll check it. Great! I will contact you when the enhancement is in CVS. Please don't hesitate to contact me if you have the feeling that I forgot it ;-) regards, Armin Guido Beutler wrote: Hi Armin, Armin Waibel wrote: Hi Guido, we can try to release the used connection on PB.close() call instead of Synchronization#beforeCompleation. For managed enviroment this seems to be better. ;-) Is it a difference or disadvantage for unmanaged enviroments? In PBFSyncImpl line 227 the close() method of PBImpl is overridden. If we are in local-tx we don't really close the used PB handle and thus do not release the used connection (it's done in #beforeCompleation). To do so we have to make PB.isInTransaction method independed from ConnectionManager.isInLocalTransaction method. After that we can release the used connection (via connectionManager) in PBSyncImpl.close method and keep PBSyncImpl still in PB-tx. Sounds like I have to take a look on it to understand what's to change. Currently I'm busy with other OJB stuff, but I will try this ASAP. Are you willing to test my changes or do you want to start this refactoring by your own? Of course I'm willing to test a fix. I'm currently a litte bit bussy too so impementing a fix on our own maybe difficult but I'll check it. thanks for the help and best regards, Guido regards, Armin Guido Beutler wrote: Hi Armin, sorry for the delay! Because nobody else had an answer I spent some time to get closer to the problem. After that I posted my question at jboss. Here's the thread: http://www.jboss.org/index.html?module=bbop=viewtopict=49041 I don't know if I am allowed to repost the answer here (copyrights etc. ) Please use the link above. I'm curious about the replies here. best regards, Guido Armin Waibel wrote: Hi Guido, Any ideas what's going on there? I only answer to say No, I don't have a clue. I assume (maybe I'm completely wrong ;-)) that JBoss has problems in handling the connections/DataSources associated with the running tx in a proper way. Your direct connection instance will be associated with the suspended tx, within the new tx OJB lookup a new connection, do all work and close the connection. It seems that the used connection is not vaild in jboss TxConnectionManager...bla, bla Reached the line count for a do my best answer ;-) regards, Armin Guido Beutler wrote: Hello, I've got a strange problem with RC6 at JBoss 3.2.3. I've got a statefull and a stateless session bean. The stateless session bean contains all OJB stuff. The statefull facade accesses some tables via JDBC directly. That stateless session OJB bean has transaction attribute RequiresNew. The facade runs with Required. Both ejb's are container managed. If a method allocates a JDBC Connection from data source and then access the OJB EJB the following exception is thrown. java.lang.IllegalStateException: Trying to return an unknown connection2! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:330) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:539) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:296) at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:117) at org.apache.ojb.broker.util.WrappedConnection.close(WrappedConnection.java:124) at org.apache.ojb.broker.util.pooling.ByPassConnection.close(ByPassConnection.java:64) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.releaseConnection(ConnectionFactoryAbstractImpl.java:79) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java:286) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion(PersistenceBrokerFactorySyncImpl.jav a:177) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion(PersistenceBrokerFactorySyncImpl.java:329) at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1308) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:398) at
