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=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!
[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) 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-------------------------------------------------------------------- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
