You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by "Clute, Andrew" <An...@osn.state.oh.us> on 2004/05/12 16:26:00 UTC
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:arminw@apache.org]
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=bb&op=viewtopic&t=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!
org.jboss.resource.adapter.jdbc.WrappedConnection@3c40f0
>>>>> 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)
>>>>> at
>>>>> org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$Transa
>>>>> ctionBox.beforeCompletion(PersistenceBrokerFactorySyncImpl.java:32
>>>>> 9)
>>>>>
>>>>> at
>>>>> org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.ja
>>>>> va:1308)
>>>>>
>>>>> at
>>>>> org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
>>>>> at
>>>>> org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxIntercepto
>>>>> rCMT.java:398)
>>>>>
>>>>> at
>>>>> org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInter
>>>>> ceptorCMT.java:325)
>>>>>
>>>>> at
>>>>> org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.jav
>>>>> a:128)
>>>>>
>>>>> at
>>>>> org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityIntercept
>>>>> or.java:118)
>>>>>
>>>>> at
>>>>>
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
>>>>> at
>>>>> org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFa
>>>>> ctoryFinderInterceptor.java:122)
>>>>>
>>>>> at
>>>>> org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSe
>>>>> ssionContainer.java:331)
>>>>>
>>>>> at org.jboss.ejb.Container.invoke(Container.java:700)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
>>>>> at
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorIm
>>>>> pl.java:39)
>>>>>
>>>>> at
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc
>>>>> cessorImpl.java:25)
>>>>>
>>>>> at java.lang.reflect.Method.invoke(Method.java:324)
>>>>> at
>>>>> org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedM
>>>>> BeanDispatcher.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(TransactionIntercept
>>>>> or.java:46)
>>>>>
>>>>> at
>>>>> org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.jav
>>>>> a:45)
>>>>>
>>>>> at
>>>>> org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSe
>>>>> ssionInterceptor.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
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> --- To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -- To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Trying to return an unknown connection2!
Posted by Armin Waibel <ar...@apache.org>.
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:arminw@apache.org]
> 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=bb&op=viewtopic&t=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!
>
> org.jboss.resource.adapter.jdbc.WrappedConnection@3c40f0
>
>>>>>> 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)
>>>>>> at
>>>>>>org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$Transa
>>>>>>ctionBox.beforeCompletion(PersistenceBrokerFactorySyncImpl.java:32
>>>>>>9)
>>>>>>
>>>>>> at
>>>>>>org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.ja
>>>>>>va:1308)
>>>>>>
>>>>>> at
>>>>>>org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
>>>>>> at
>>>>>>org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxIntercepto
>>>>>>rCMT.java:398)
>>>>>>
>>>>>> at
>>>>>>org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInter
>>>>>>ceptorCMT.java:325)
>>>>>>
>>>>>> at
>>>>>>org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.jav
>>>>>>a:128)
>>>>>>
>>>>>> at
>>>>>>org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityIntercept
>>>>>>or.java:118)
>>>>>>
>>>>>> at
>>>>>>
>
> org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
>
>>>>>> at
>>>>>>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFa
>>>>>>ctoryFinderInterceptor.java:122)
>>>>>>
>>>>>> at
>>>>>>org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSe
>>>>>>ssionContainer.java:331)
>>>>>>
>>>>>> at org.jboss.ejb.Container.invoke(Container.java:700)
>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>
> Method)
>
>>>>>> at
>>>>>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorIm
>>>>>>pl.java:39)
>>>>>>
>>>>>> at
>>>>>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc
>>>>>>cessorImpl.java:25)
>>>>>>
>>>>>> at java.lang.reflect.Method.invoke(Method.java:324)
>>>>>> at
>>>>>>org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedM
>>>>>>BeanDispatcher.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(TransactionIntercept
>>>>>>or.java:46)
>>>>>>
>>>>>> at
>>>>>>org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.jav
>>>>>>a:45)
>>>>>>
>>>>>> at
>>>>>>org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSe
>>>>>>ssionInterceptor.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
>>>>>>
>>>>>>------------------------------------------------------------------
>>>>>>--- To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>-------------------------------------------------------------------
>>>>>-- To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>--------------------------------------------------------------------
>>>>- To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org