I fixed the immediate problem in jboss 3.2, other versions to follow
shortly.
The intent of this feature is to encourage you to clean up after yourself
by closing all database connections you get before you leave the ejb method
they were obtained in. This is contrary to the jca spec requirement that
the app server allow you to hold connection handles across ejb method
invocations, hooking the handle up to a suitable (tx and security)
ManagedConnection for each ejb call. I cannot emphasize enough how
strongly I advise you to obtain and close your connection handles in each
ejb call.
If you require holding connection handles over method invocations, set the
CachedConnectionManager SpecCompliant attribute to true in the
jboss-jca.sar/META-INF/jboss-service.xml file.
I can't imagine how your code could have worked with the previous jboss
code without running out of connection handles just as fast, so if there
are additional problems please let me know.
thanks
david jencks
On 2003.02.20 05:19 Jonas Partner wrote:
> Hi
> I was hoping that someone could provide guidance on whether we should
> continue trying to develop with 3.2
> or whether to try and drop back to 3.0.x, at the moment 3.2 RC1, RC2 and
> a clean 3.2 build from CVS do not seem
> to be closing local transaction database connections see the below stack
> from the testsuite. This is proving
> critical since under moderate usage we can quickly run out of connections
> .Since we have a freeze date
> approaching in the next week or two we are looking for guidance as to
> when the changes in connection
> management are likely to be completed and also whether any assistance
> with this would be welcome.
>
> Regards
>
> Jonas Partner
> Software Developer
> Xerox Mobile Solutions
> Cambridge
>
>
> 2003-02-20 09:20:38,100 INFO [org.jboss.test.jca.ejb.CachedConnectionSessionBean]
> ejb activate never called, conn == null
> 2003-02-20 09:20:38,100 INFO
>[org.jboss.resource.connectionmanager.CachedConnectionManager]
> Could not find a close method on alleged connection objects. Please
> close your own connections.
> java.lang.Exception: Stack Trace
> at
>org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:357)
> at
>org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199)
> at
>org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190)
> at
>org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)
> at
>org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:108)
> at
>org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:243)
> at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104)
> at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)
> at
>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154)
> at
>org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:322)
> at org.jboss.ejb.Container.invoke(Container.java:652)
> 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:549)
> at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:338)
> at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
> at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> at sun.rmi.transport.Transport$1.run(Transport.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> at java.lang.Thread.run(Thread.java:536)
>
>
>
>
>
>
>
> Hi
> I was hoping that someone could provide
> guidance on
> whether we should continue trying to develop with 3.2
> or whether to try and drop back to
> 3.0.x, at the moment 3.2 RC1, RC2 and
> a
> clean 3.2 build from CVS do not seem
> to be closing local transaction database
> connections see the below stack from the
> testsuite. This is proving
> critical since under moderate usage
> face=Arial size=2>w
