db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clute, Andrew" <Andrew.Cl...@osn.state.oh.us>
Subject RE: Trying to return an unknown connection2!
Date Wed, 12 May 2004 14:26:00 GMT
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


Mime
View raw message