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)
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
> <META content="MSHTML 6.00.2800.1126" name=GENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=#ffffff>
> <DIV><FONT face=Arial size=2>Hi </FONT></DIV>
> <DIV><FONT face=Arial size=2>I was hoping that someone could provide
> guidance on 
> whether we should continue trying to develop with 3.2</FONT></DIV>
> <DIV><FONT face=Arial size=2>or whether to try and drop back to 
> 3.0.x,&nbsp;</FONT><FONT face=Arial size=2>at the moment 3.2 RC1, RC2 and
> a 
> clean 3.2&nbsp;build from CVS do not seem </FONT></DIV>
> <DIV><FONT face=Arial size=2>to be closing local transaction database 
> </FONT><FONT face=Arial size=2>connections see the below stack from the 
> testsuite.&nbsp; This is proving </FONT></DIV>
> <DIV><FONT face=Arial size=2>critical since under moderate usage
> </FONT><FONT 
> face=Arial size=2>we can quickly run out of connections .Since we have 
> a&nbsp;freeze date </FONT></DIV>
> <DIV><FONT face=Arial size=2>approaching in the next </FONT><FONT
> face=Arial 
> size=2>week or two </FONT><FONT face=Arial size=2>we are looking for
> guidance as 
> to when the changes in connection </FONT></DIV>
> <DIV><FONT face=Arial size=2>management are likely to be completed
> </FONT><FONT 
> face=Arial size=2>and also whether any </FONT><FONT face=Arial><FONT 
> size=2>assistance with this would be welcome.</FONT></FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>Regards </FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>Jonas Partner</FONT></DIV>
> <DIV><FONT face=Arial size=2>Software Developer</FONT></DIV>
> <DIV><FONT face=Arial size=2>Xerox Mobile Solutions</FONT></DIV>
> <DIV><FONT face=Arial size=2>Cambridge</FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>2003-02-20 09:20:38,100 INFO&nbsp; 
> [org.jboss.test.jca.ejb.CachedConnectionSessionBean] ejb activate never
> called, 
> conn == null<BR>2003-02-20 09:20:38,100 INFO&nbsp; 
> [org.jboss.resource.connectionmanager.CachedConnectionManager] Could not
> find a 
> close method on alleged connection objects.&nbsp; Please close your own 
> connections.<BR>java.lang.Exception: Stack Trace<BR>&nbsp;at 
> 
>org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:357)<BR>&nbsp;at
> 
> 
>org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199)<BR>&nbsp;at
> 
> 
>org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190)<BR>&nbsp;at
> 
> 
>org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)<BR>&nbsp;at
> 
> 
>org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:108)<BR>&nbsp;at
> 
> 
>org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:243)<BR>&nbsp;at
> 
> org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104)<BR>&nbsp;at
> 
> 
>org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)<BR>&nbsp;at
> 
> org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)<BR>&nbsp;at
> 
> 
>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154)<BR>&nbsp;at
> 
> 
>org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:322)<BR>&nbsp;at
> 
> org.jboss.ejb.Container.invoke(Container.java:652)<BR>&nbsp;at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<BR>&nbsp;at 
> 
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)<BR>&nbsp;at
> 
> 
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)<BR>&nbsp;at
> 
> java.lang.reflect.Method.invoke(Method.java:324)<BR>&nbsp;at 
> 
>org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)<BR>&nbsp;at
> 
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)<BR>&nbsp;at
> 
> org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:338)<BR>&nbsp;at
> 
> sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)<BR>&nbsp;at 
> 
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)<BR>&nbsp;at
> 
> java.lang.reflect.Method.invoke(Method.java:324)<BR>&nbsp;at 
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)<BR>&nbsp;at
> 
> sun.rmi.transport.Transport$1.run(Transport.java:148)<BR>&nbsp;at 
> java.security.AccessController.doPrivileged(Native Method)<BR>&nbsp;at 
> sun.rmi.transport.Transport.serviceCall(Transport.java:144)<BR>&nbsp;at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)<BR>&nbsp;at
> 
> 
>sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)<BR>&nbsp;at
> 
> java.lang.Thread.run(Thread.java:536)</FONT></DIV></BODY></HTML>
> 


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to