RE: STILL TRYING: [JBoss-user] CMP: Iterate Collection PerformanceKiller
Yes, you can. Look at this http://www.jboss.org/online-manual/HTML/ch07s16.html alex > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dennis > Muhlestein > Sent: Monday, April 29, 2002 5:26 PM > To: [EMAIL PROTECTED] > Subject: Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection > PerformanceKiller > > > It makes sense to change the commit option for transactions for > performance tuning. I have one Entity Bean that I think would fit > option A better, and others that fit option B better. > > Can I customize each entity bean? I tried putting read-only > to true on > the one bean, but the container still loaded it before each > transaction. > (Option B). I don't want to change everything to option A. > > Thanks > -Dennis > > > On Fri, 2002-04-26 at 10:29, Dan Christopherson wrote: > > First, the re-fetch you see between your two tests is > because of the > > commit option. Option B (default in 3.0) doesn't cache data between > > transactions, although the bean instances will be cached. > If you aren't > > clustering and your data can't be modified from anywhere > else, you can > > change standardjboss.xml to use Option A instead. > > > > As to why you need the user transaction, what kind of > object are you > > calling from? If it's a client, well then you need a > UserTransaction. If > > it's a session bean, then make sure your session bean's > method is in a > > transaction with type of Required or RequiresNew. > > > > hth, > > danch > > > > Frank Morton wrote: > > > > > > If I wrap it with a UserTransaction, things look good, but I don't > > > see why I would have to do so. And, if I do, I have many places > > > where I will have to do the same thing, which I would > like to avoid. > > > > > > Without wrapping in my own transaction, when trying to > get a single > > > property from a single element in the Collection, it > loads the whole > > > Collection. I don't understand why it would do it twice, let alone > > > for each element in the Collection. I also don't understand if it > > > is a function of the commit options, config or it is not working > > > as expected. > > > > > > > > ___ > > 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
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection PerformanceKiller
It makes sense to change the commit option for transactions for performance tuning. I have one Entity Bean that I think would fit option A better, and others that fit option B better. Can I customize each entity bean? I tried putting read-only to true on the one bean, but the container still loaded it before each transaction. (Option B). I don't want to change everything to option A. Thanks -Dennis On Fri, 2002-04-26 at 10:29, Dan Christopherson wrote: > First, the re-fetch you see between your two tests is because of the > commit option. Option B (default in 3.0) doesn't cache data between > transactions, although the bean instances will be cached. If you aren't > clustering and your data can't be modified from anywhere else, you can > change standardjboss.xml to use Option A instead. > > As to why you need the user transaction, what kind of object are you > calling from? If it's a client, well then you need a UserTransaction. If > it's a session bean, then make sure your session bean's method is in a > transaction with type of Required or RequiresNew. > > hth, > danch > > Frank Morton wrote: > > > > If I wrap it with a UserTransaction, things look good, but I don't > > see why I would have to do so. And, if I do, I have many places > > where I will have to do the same thing, which I would like to avoid. > > > > Without wrapping in my own transaction, when trying to get a single > > property from a single element in the Collection, it loads the whole > > Collection. I don't understand why it would do it twice, let alone > > for each element in the Collection. I also don't understand if it > > is a function of the commit options, config or it is not working > > as expected. > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > signature.asc Description: This is a digitally signed message part
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection PerformanceKiller
Frank Morton wrote: >>You have specified Bean. Then I think >> >> >you have to manually start and end the transaction. Do you do this? And I >think you should use container for this option instead, and Required in the >transaction-type of your methods. > >I am not starting/ending the transaction manually and >I haven't been able to find a description how to do it. >If you can point me at how to do that, I'd appreciate it. > >Thanks for your help. > > > somthing like this in your ejb-jar.xml: beanName * bean2name * Required I think required may be the default, or nothing? ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection PerformanceKiller
Frank Morton wrote: >>You have specified Bean. Then I think >> >> >you have to manually start and end the transaction. Do you do this? And I >think you should use container for this option instead, and Required in the >transaction-type of your methods. > >I am not starting/ending the transaction manually and >I haven't been able to find a description how to do it. >If you can point me at how to do that, I'd appreciate it. > >Thanks for your help. > > > Take a look in a EJB-book under transactions (you should really have one when using EJB) or maybe the jboss-book (in paper or online for 10$), but you probably don't need it. Just change to Container and in the transaction set methods=* type=required, possibly with the help of xdoclet. ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection PerformanceKiller
You have specified Bean. Then I think you have to manually start and end the transaction. Do you do this? And I think you should use container for this option instead, and Required in the transaction-type of your methods. Frank Morton wrote: >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: > > > > > > Container Session Beans > Container Session Beans > > > ContainerControl > >com.base2inc.bean.session.container.ContainerControlHome > >com.base2inc.bean.session.container.ContainerControl > >com.base2inc.bean.session.container.ContainerControlBeanss> > Stateless > Bean > > > ContainerValue > com.base2inc.bean.session.container.ContainerValueHome > com.base2inc.bean.session.container.ContainerValue > >com.base2inc.bean.session.container.ContainerValueBean > > Stateless > Bean > > > > > > >ContainerControl >* > > Required > > > > >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. >> >> >> >> AttributeManager >> * >> >>Required >> >> >>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 >>>with the on-load 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 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: >>> >>> >>> >>> >>> Attribute Management >>> Attribute Management >>> >>> >>> >>> Attribute >>> Attribute >>
