Dan the answer man. > Your pool shouldn't be a problem (unless you have a lot of users all > trying to do this at the same time). Umm, yes, I may have a lot of users at one time. It happens when users try and look at thier order history on the website. I have no control over how many of them will do this at the same time. However, I see the issue as with only one user who has a lot of history.
> Are you calling the finder from a session bean, or directly from UI? If > directly from the UI, step one is going to be to change that so that the > finder gets called from a session bean which passes back some sort of > value objects to the UI. Accessing entities from the UI is bound to > hurt, because each call will be its own transaction. A session bean calls the finder, then calls a method on each entity bean to get a serializable object representing the bean data needed, and returns an array to the servlet code. > For CMP, once you're calling from a session bean, look at the read-ahead > element in jaws.xml (CMP1.1) or jbosscmp-jdbc.xml (CMP2.0). This should > help tremendously. Using CMP2.0 with default settings: strategy: on-load page-size: 1000 eager-load-group: * What I also find interesting is I get the following messages in the log in the minutes following a re-deploy of my beans: DEBUG [org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy] Resized cache for bean FooBean: old capacity = 1000000, new capacity = 50 I don't know where it gets 50 or if it has anything to do with my issue. _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
