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
