Have you looked at the server.log? What queries are being executed? Don't post the whole file. Give us a summary.
-dain BTW: there is a difference between doesn't work and is not fast enough for me. Frank Morton wrote: > Maybe I should try a different tactic..... > > Does anyone have an entity bean that has a method that > returns a Collection that performs well with ~200 elements > in the Collection? Reaching it through a session bean is > fine. If so, would you share the source? I'm beginning to > believe that no one actually has done this successfully. > > Still working on this without success. I have tried all > suggestions, including wrapping it with a UserTransaction, > but still didn't make any difference. > > Still wanting cmp to work.............. > > >>I think I'm close.Thanks to all who have given advice. If I get >>this going, I'll be glad to write up the results, which based on >>dain's comments, others are also asking about. Here are the >>details (using 3.0.0.RC1): >> >>I have two cmp entity beans: Container and Attribute. >> >>I also have a stateless session bean called ContainerControl. In this >>class, there is a method called findByPrimaryKeyMap. This method >>does a findByPrimaryKey on a Container. It also does a >>findByContainerId, which returns a Collection of ~ 200 elements >>on Attribute, causing the performance problem. The findByPrimaryKeyMap >>method returns what I call a ContainerMap, which encapsulates >>the two find results as well as build a lookup table of the Collection. >> >>I have a web application that does the following: >> >>ContainerControl containerControl = Factory.getContainerControl(); >>ContainerMap containerMap = >> > containerControl.findByPrimaryKeyMap(id,"name"); > >>CollectionMap attributeMap = containerMap.getAttributeMap(); >> >>Basically looks up the session bean, does the find and gets the results >>out of the ContainerMap. When the ContainerMap is built, it iterates >>the Collection, taking over 100 ms per element. Based on that, each >>step must still think it is a transaction. >> >>Based on the ejb-jar below, I think the session bean ought to be a single >>transaction, but it isn't. The ContainerControl ejb-jar.xml files looks >>like: >> >> >><?xml version="1.0" encoding="UTF-8"?> >> >><ejb-jar> >> <description>Container Session Beans</description> >> <display-name>Container Session Beans</display-name> >> <enterprise-beans> >> <session> >> <ejb-name>ContainerControl</ejb-name> >> >><home>com.base2inc.bean.session.container.ContainerControlHome</home> >> >><remote>com.base2inc.bean.session.container.ContainerControl</remote> >> >> > <ejb-class>com.base2inc.bean.session.container.ContainerControlBean</ejb-cla > >>ss> >> <session-type>Stateless</session-type> >> <transaction-type>Bean</transaction-type> >> </session> >> <session> >> <ejb-name>ContainerValue</ejb-name> >> > <home>com.base2inc.bean.session.container.ContainerValueHome</home> > > <remote>com.base2inc.bean.session.container.ContainerValue</remote> > >> > <ejb-class>com.base2inc.bean.session.container.ContainerValueBean</ejb-class > >> <session-type>Stateless</session-type> >> <transaction-type>Bean</transaction-type> >> </session> >> </enterprise-beans> >> >> <assembly-descriptor> >> <container-transaction> >> <method> >> <ejb-name>ContainerControl</ejb-name> >> <method-name>*</method-name> >> </method> >> <trans-attribute>Required</trans-attribute> >> </container-transaction> >> </assembly-descriptor> >></ejb-jar> >> >>Any idea will be tried. Thanks. >> >> >> >>>You must use a transaction for your unseen session bean that is >>> > accessing > >>>the entity beans. Otherwise, as Dain says, everytime you change a bean >>> > in > >>>the collection, it creates a transaction, reads ahead 1000 or so >>> >>(depending >> >>>upon read-ahead limit) then when you edit the bean, it commits the >>>transaction, which loses all the read-ahead information. Then as you >>> > edit > >>>the next bean, it starts the whole process over again. >>> >>>If your session bean was called AttributeManager, you would use a >>>container-transaction like the following in the assembly-descriptor >>> >>element. >> >>>This way, the transactions on the Attribute bean are encompassed by the >>>transaction on the session bean method that is iterating over the >>>collection. >>> >>> <container-transaction> >>> <method> >>> <ejb-name>AttributeManager</ejb-name> >>> <method-name>*</method-name> >>> </method> >>> <trans-attribute>Required</trans-attribute> >>> </container-transaction> >>> >>>Michael >>> >>> >>>>-----Original Message----- >>>>From: Frank Morton [mailto:[EMAIL PROTECTED]] >>>>Sent: Tuesday, April 23, 2002 11:50 AM >>>>To: [EMAIL PROTECTED] >>>>Subject: Re: [JBoss-user] CMP: Iterate Collection Performance Killer >>>> >>>> >>>> >>>>>Use a transaction or turn off read ahead. You are basically reading >>>>>ahead data, tossing the read-ahead information out, and >>>>> >>>>then repeating. >>>> >>>>>-dain >>>>> >>>>Thanks for your response. >>>> >>>>Sorry for my confusion, but I am. Your doc states to use <read-ahead> >>>>with the <strategy>on-load</strategy> for this exact case, but doesn't >>>>seem to make a difference at this point. You are saying strategy=none >>>>is the right thing to do? I tried that, too, which doesn't >>>>appear to make >>>>any difference. Please clarify this. There is a lot of contradictory >>>>info on the web about this. I also tried setting <read-ahead> in >>>>standardjaws.xml to true and false, neither of which seemed to >>>>make any difference. Seems no matter what I do, I get the >>>>same behavior, so I must be missing something. >>>> >>>>While I'm irritating you, can you explain exactly how or refer me to >>>>someplace that explains exactly how to use a transaction to speed up >>>>reading Collections. >>>> >>>>Thanks. I'm guessing I'm not the only one that needs to know >>>>about this. >>>> >>>>Frank >>>> >>>>Here is my ejb-jar.xml file in case it is of use to you: >>>> >>>><?xml version="1.0" encoding="UTF-8"?> >>>> >>>><ejb-jar> >>>> <description>Attribute Management</description> >>>> <display-name>Attribute Management</display-name> >>>> >>>> <enterprise-beans> >>>> <entity> >>>> <description>Attribute</description> >>>> <ejb-name>Attribute</ejb-name> >>>> >>>><local-home>com.base2inc.bean.entity.attribute.AttributeHome</ >>>> >>>local-home> >>> >>>><local>com.base2inc.bean.entity.attribute.Attribute</local> >>>> >>>><ejb-class>com.base2inc.bean.entity.attribute.AttributeBean</e >>>>jb-class> >>>> <persistence-type>Container</persistence-type> >>>> <prim-key-class>java.lang.Long</prim-key-class> >>>> <reentrant>False</reentrant> >>>> <cmp-version>2.x</cmp-version> >>>> >>>><cmp-field><field-name>id</field-name><jdbc-type>BIGINT</jdbc- >>>>type></cmp-fie >>>>ld> >>>> >>>><cmp-field><field-name>containerId</field-name><jdbc-type>BIGI >>>>NT</jdbc-type> >>>></cmp-field> >>>> >>>><cmp-field><field-name>containerType</field-name></cmp-field> >>>> <cmp-field><field-name>name</field-name></cmp-field> >>>> <cmp-field><field-name>value</field-name></cmp-field> >>>> <primkey-field>id</primkey-field> >>>> <read-ahead> >>>> <strategy>on-load</strategy> >>>> <limit>255</limit> >>>> <cache-size>1000</cache-size> >>>> </read-ahead> >>>> </entity> >>>> </enterprise-beans> >>>> >>>> <assembly-descriptor> >>>> <container-transaction> >>>> <method> >>>> <ejb-name>Attribute</ejb-name> >>>> <method-name>*</method-name> >>>> </method> >>>> <trans-attribute>Required</trans-attribute> >>>> </container-transaction> >>>> </assembly-descriptor> >>>> >>>></ejb-jar> >>>> >>>>Frank Morton wrote: >>>> >>>>>>Using 3.0.0RC1 with PostgreSQL underneath. Just converted >>>>>>to using a Local Interface, but didn't make as much performance >>>>>>difference as I hoped. >>>>>> >>>>>>I have a case where I need to iterate a Collection resulting from >>>>>>a finder method with an entity bean. Since the collection >>>>>> >>>>might have >>>> >>>>>>200 items, performance is very bad iterating the Collection. >>>>>>(I do have an index on the field used for finding). >>>>>> >>>>>>Using a Collection in the first place is what I would like to do >>>>>>since some of the elements require an update. But, since I >>>>>>know I will be looking at each item in the Collection, is there >>>>>>some way to fetch the content of the collection as a group >>>>>>prior to iterating instead of getting killed by the performance >>>>>>of fetching one at a time? >>>>>> >>>>>> >> >> >>_______________________________________________ >>JBoss-user mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-user >> >> > > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
