RE: [JBoss-user] A little BMP philosophy/understanding
In the original JBoss 2.0 version the PreparedStatement cache was not discarded after the connection was returned to the pool because more than likely you might want to issue that one of these PreparedStatements again. To make matters worse there wasn't an upper limit on the number of PreparedStatement objects in the cache so things would continue to grow as you prepared new SQL statements. If you happened to prepare the same exact SQL statement then you received the previously cached PreparedStatement object but otherwise you got a new PreparedStatement that was also added to the cache. This would continue until either a) the database complained or b) you ran out of memory which ever came first. On Oracle, for example, each PreparedStatement takes memory on the database and once you hit 100 or so the database throws an exception when you try to get another one. I patched the code by releasing the PreparedStatement cache when the Connection was released and submitted that fix but I'm not sure it was accepted. What really needs to happen is that the PreparedStatement cache needs to be enhanced so that an upper bound can be established via a configuration variable so that after x PreparedStatements have been cached new PreparedStatements will push one of the old ones out of the cache. - Jon Harvie Mike Jau <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/22/2001 12:42 PM Please respond to jboss-user To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject: RE: [JBoss-user] A little BMP philosophy/understanding Could you give me some background information about the Preparedstaement caching on the EJB container side? Since the connection get from pool need to return to pool once the transaction done. I assumed that the resouce associate to this connection should be released and the released resoure include the preparedstatement. Later on, the create preparedstatement will be invoked again from different connection. How the preparedstatement cached is my question? - Mike -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 12:10 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] A little BMP philosophy/understanding Dan Christopherson wrote: > On Fri, 23 Mar 2001, Peter Routtier-Wone wrote: > >>> Someone from this discussion group indicate that container might cache the >>> PreparedStatement. >> >> I can't speak with authority on this, but that rings true. I'm guessing that >> interception doesn't happen for the setEntityContext() method and therefore >> you actually create a PreparedStatement rather than receiving one from the >> pool. >> >>> Just for kicks, I gave it a try but transactions weren't completed and >>> they'd just hang out there forever, blocking every other persistence and >>> finder method until they timed out. >> >> That would bollox lifecycle management, and the described behaviour wouldn't >> be at all surprising. > > This is also a common bean bug: 'close()' should be called on every > resultset, statement, and connection in a finally clause so that you know > it happens every time. > >> On the other hand, I'd have thought that PreparedStatements would be far >> less costly to manufacture than Connections, and therefore not worth the >> overhead of managing a pool. I think I'll poke my nose into the source and >> see what's there. > > There's often communication with the database to create the > PreparedStatement. That way it can pre-compile a query plan. There is a > prepared statement cache in JBoss: in JBoss 2.0, it caused problems with > Oracle's cursor limit (fixed in 2.1). I'm re-writing the minerva PreparedStatement caching so it handles cursor limit better. I'll submit the code tomorrow after I test it. Bill ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Autodeployer classpath changes in Version 2.1
I did as you suggested but I'm still receiving the same exception. I will attempt to isolate the problem further. Thanks for the input. "Scott M Stark" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/19/2001 12:52 PM Please respond to jboss-user To: <[EMAIL PROTECTED]> cc: Subject: Re: [JBoss-user] Autodeployer classpath changes in Version 2.1 The feature is still there and works. The issue is most likely that the log4j.jar that comes with jboss is an older version that uses the original org.log4j.* packages rather than the newer org.apache.log4j.* packages. Rename the existing log4j.jar and add your version. ext 547>jar -tf log4j.jar META-INF/ META-INF/MANIFEST.MF org/log4j/OptionHandler.class org/log4j/Appender.class org/log4j/Layout.class - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 19, 2001 6:25 AM Subject: [JBoss-user] Autodeployer classpath changes in Version 2.1 I am using JBoss 2.1 (or at least attempting to) on Window 2000. I have been using JBoss 2.0 without any problems for several months. However, if I take the ejb-jar file that works under version 2.0 and attempt to use in JBoss 2.1 I receive a java.lang.NoClassDefFoundError when the JBoss verifier attempts to load my jar file containing the EJB beans. In version 2.0 of JBoss I was able to add additional JAR files (like bsf.jar or log4j.jar) to the JBoss/lib/ext directory. The class loader would then be able to find these classes when I imported them from within my EJB classes. It seems that feature has either been removed from version 2.1 or is broken. Could someone please tell if this feature is have removed or is simply broken. If the feature has been removed could you please let me know how to get the classloader to find classes in another JAR file (such as log4j.jar) so that I can get my code working again. Thanks, Jon Harvie InSession Technologies Here is the complete exception: [Verifier] java.lang.NoClassDefFoundError: org/apache/log4j/Category [Verifier] at com.workpoint.server.ejb.GenericBean.(com/workpoint/server/ejb/GenericBean) [Verifier] at java.lang.Class.newInstance0(Native Method) [Verifier] at java.lang.Class.newInstance(Unknown Source) [Verifier] at org.jboss.verifier.strategy.AbstractVerifier.hasDefaultConstructor(AbstractVerifier.java:334) [Verifier] at org.jboss.verifier.strategy.EJBVerifier11.verifySessionBean(EJBVerifier11.java:625) [Verifier] at org.jboss.verifier.strategy.EJBVerifier11.checkSession(EJBVerifier11.java:92) [Verifier] at org.jboss.verifier.BeanVerifier.verify(BeanVerifier.java:134) [Verifier] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:416) [Verifier] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:333) [Verifier] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:274) [Verifier] at java.lang.reflect.Method.invoke(Native Method) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [Verifier] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:430) [Verifier] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:178) [Verifier] at java.lang.reflect.Method.invoke(Native Method) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [Verifier] at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:358) [Verifier] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:221) [Verifier] at org.jboss.ejb.AutoDeployer.startService(AutoDeployer.java:332) [Verifier] at org.jboss.util.ServiceMBeanSupport.start(ServiceMBeanSupport.java:93) [Verifier] at java.lang.reflect.Method.invoke(Native Method) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [Verifier] at org.jboss.util.ServiceControl.start(ServiceControl.java:97) [Verifier] at java.lang.reflect.Method.invoke(Native Method) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [Verifier] at org.jboss.Main.(Main.java:190) [Verifier] at org.jboss.Main$1.run(Main.java:94) [Verifier] at java.security.AccessController.doPrivileged(Native Method) [Verifier] at org.jboss.Main.main(Main.java:90) ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Autodeployer classpath changes in Version 2.1
I am using JBoss 2.1 (or at least attempting to) on Window 2000. I have been using JBoss 2.0 without any problems for several months. However, if I take the ejb-jar file that works under version 2.0 and attempt to use in JBoss 2.1 I receive a java.lang.NoClassDefFoundError when the JBoss verifier attempts to load my jar file containing the EJB beans. In version 2.0 of JBoss I was able to add additional JAR files (like bsf.jar or log4j.jar) to the JBoss/lib/ext directory. The class loader would then be able to find these classes when I imported them from within my EJB classes. It seems that feature has either been removed from version 2.1 or is broken. Could someone please tell if this feature is have removed or is simply broken. If the feature has been removed could you please let me know how to get the classloader to find classes in another JAR file (such as log4j.jar) so that I can get my code working again. Thanks, Jon Harvie InSession Technologies Here is the complete exception: [Verifier] java.lang.NoClassDefFoundError: org/apache/log4j/Category [Verifier] at com.workpoint.server.ejb.GenericBean.(com/workpoint/server/ejb/GenericBean) [Verifier] at java.lang.Class.newInstance0(Native Method) [Verifier] at java.lang.Class.newInstance(Unknown Source) [Verifier] at org.jboss.verifier.strategy.AbstractVerifier.hasDefaultConstructor(AbstractVerifier.java:334) [Verifier] at org.jboss.verifier.strategy.EJBVerifier11.verifySessionBean(EJBVerifier11.java:625) [Verifier] at org.jboss.verifier.strategy.EJBVerifier11.checkSession(EJBVerifier11.java:92) [Verifier] at org.jboss.verifier.BeanVerifier.verify(BeanVerifier.java:134) [Verifier] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:416) [Verifier] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:333) [Verifier] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:274) [Verifier] at java.lang.reflect.Method.invoke(Native Method) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [Verifier] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:430) [Verifier] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:178) [Verifier] at java.lang.reflect.Method.invoke(Native Method) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [Verifier] at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:358) [Verifier] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:221) [Verifier] at org.jboss.ejb.AutoDeployer.startService(AutoDeployer.java:332) [Verifier] at org.jboss.util.ServiceMBeanSupport.start(ServiceMBeanSupport.java:93) [Verifier] at java.lang.reflect.Method.invoke(Native Method) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [Verifier] at org.jboss.util.ServiceControl.start(ServiceControl.java:97) [Verifier] at java.lang.reflect.Method.invoke(Native Method) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [Verifier] at org.jboss.Main.(Main.java:190) [Verifier] at org.jboss.Main$1.run(Main.java:94) [Verifier] at java.security.AccessController.doPrivileged(Native Method) [Verifier] at org.jboss.Main.main(Main.java:90)
