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

Reply via email to