Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
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
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
> > I have neither a jbosscmp-jdbc.xml or a jaws.xml, assuming it would > > use standard setting if missing. Is that right? > > > Yes if you don't want to tune loading, but then you are not allowed to > complain about speed. > > -dain >From advice from all of you, I have converted all my beans to truly use the 2.0 spec. I also have defined a jbosscmp-jdbc.xml for each bean so I can be allowed to complain about speed ;-) I have also become friends with the dtds and am writing my config files actually looking at them. Highly recommended for all who are lazy like me. I have some minor questions, but I'll get to my big one. I have seen glimmers of very big speed improvements after my conversion, but I have had to use UserTransactions to get what I would expect to be normal behavior without them. Below is a long log with my commentary about what is happening. Basically it is the same Collection iteration issue. I am doing a query resulting in around 200 "Attribute" beans in a Collection, iterating through the collection and getting a simple property from each "Attribute" to build a HashMap of Attributes using the "name" property as the key for the HashMap. 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. Here is the log with my commentary preceded by > I have taken out a lot of stuff to make it shorter, but it is still pretty long. Thanks. > build the Collection of Attributes 2002-04-26 09:26:53,066 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCFindByQuery.Attribute.findByContainerId] Executing SQL: SELECT id FROM attribute WHERE containerId=? 2002-04-26 09:26:53,175 ERROR [STDERR] DEBUG: prep time for collection map: 1 2002-04-26 09:26:53,177 ERROR [STDERR] DEBUG: class used in the reflection: $Proxy171 2002-04-26 09:26:53,179 ERROR [STDERR] DEBUG: field name: name 2002-04-26 09:26:53,191 ERROR [STDERR] DEBUG: just getting the method time is0 > begin to iterate the Collection and get the "name" property for indexing > this loads the whole collection which is perfect 2002-04-26 09:26:53,193 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: [1006166] getName() 2002-04-26 09:26:53,196 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.Attribute] Executing SQL: SELECT id,containerId, containerType, name, value FROM attribute WHERE (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR ! (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) 2002-04-26 09:26:55,146 DEBUG [org.jboss.jetty.util.NaiveTimeOutManager] background thread ended: org.jboss.jetty.util.NaiveTimeOutManager@466eea > still takes 3 seconds to do this.beats 20 seconds though 2002-04-26 09:26:56,244 ERROR [STDERR] DEBUG: invoking method time is3054 2002-04-26 09:26:56,249 ERROR [STDERR] DEBUG: add field time: 3072 2002-04-26 09:26:56,251 ERROR [STDERR] DEBUG: class used in the reflection: $Proxy171
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
Frank Morton wrote: >>Does your ejb-jar have a jbosscmp-jdbc.xml, or a jaws.xml? It should >>be only jbosscmp-jdbc.xml (although any jaws.xml should be ignored by >>JBoss 3.0 or later). Trying to use jaws.xml with JBoss 3.x is getting >>to be a FAQ issue, but I know Dain's been trying to help you with this >>so I imagine you've got this right. >> > > I have neither a jbosscmp-jdbc.xml or a jaws.xml, assuming it would > use standard setting if missing. Is that right? Yes if you don't want to tune loading, but then you are not allowed to complain about speed. -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
> Does your ejb-jar have a jbosscmp-jdbc.xml, or a jaws.xml? It should > be only jbosscmp-jdbc.xml (although any jaws.xml should be ignored by > JBoss 3.0 or later). Trying to use jaws.xml with JBoss 3.x is getting > to be a FAQ issue, but I know Dain's been trying to help you with this > so I imagine you've got this right. I have neither a jbosscmp-jdbc.xml or a jaws.xml, assuming it would use standard setting if missing. Is that right? Frank ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
danch wrote: > Hmm. > Well I can help with JAWS: JAWS really should be removed from the 3.0 > codebase because even if you deploy a vanilla 1.1 CMP bean, Dain's > JDBCStoreManager should be handling it (uh, right, Dain?). It should. It is not used much, so the code is probably more buggy. > To paraphrase Monty Python, "JAWS is dead! it is deceased! it is no more!" This is a backwards compatibility issue. I except to fully remove JAWS in JBoss 4.0. > From the trace, JAWS isn't trying to do read-ahead. For the historic > record, read-ahead defaulted off in JAWS. > > Does your ejb-jar have a jbosscmp-jdbc.xml, or a jaws.xml? It should be > only jbosscmp-jdbc.xml (although any jaws.xml should be ignored by JBoss > 3.0 or later). Trying to use jaws.xml with JBoss 3.x is getting to be a > FAQ issue, but I know Dain's been trying to help you with this so I > imagine you've got this right. > > I'll try to take a look tonight and see why 3.0 would use JAWS at all. It is used for applications that do not use the new EJB 2.0 dtd for the ejb-jar.xml file. This is an EJB 1.1 jar and therefore CMP 1.1. -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
Frank Morton wrote: >>Wait. Are you using JAWS? I only ask that because all of the log stuff >>is from JAWS. >> >>If you are using JAWS, I can't help, because I don't know anything about >>the JAWS optimized loading process. >> >>-dain >> > > Well, I'm using 3.0 as distributed. I assumed if I set cmp-version to "2.x" > that I would be using the persistence-manager for Standard CMP 2.x > EntityBean, which in standardjboss.xml is orgJDBCStoreManager. > So, to answer your question as best I can, I don't think so > and I'm thinking if I am, it is by accident and shouldn't be the case. > JAWS is for pre-2.0, right? Can you shed light on this? > > Frank > Hmm. Well I can help with JAWS: JAWS really should be removed from the 3.0 codebase because even if you deploy a vanilla 1.1 CMP bean, Dain's JDBCStoreManager should be handling it (uh, right, Dain?). To paraphrase Monty Python, "JAWS is dead! it is deceased! it is no more!" From the trace, JAWS isn't trying to do read-ahead. For the historic record, read-ahead defaulted off in JAWS. Does your ejb-jar have a jbosscmp-jdbc.xml, or a jaws.xml? It should be only jbosscmp-jdbc.xml (although any jaws.xml should be ignored by JBoss 3.0 or later). Trying to use jaws.xml with JBoss 3.x is getting to be a FAQ issue, but I know Dain's been trying to help you with this so I imagine you've got this right. I'll try to take a look tonight and see why 3.0 would use JAWS at all. -danch ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
Frank Morton wrote: >>Wait. Are you using JAWS? I only ask that because all of the log stuff >>is from JAWS. > > Well, I'm using 3.0 as distributed. I assumed if I set cmp-version to "2.x" > that I would be using the persistence-manager for Standard CMP 2.x > EntityBean, which in standardjboss.xml is orgJDBCStoreManager. > So, to answer your question as best I can, I don't think so > and I'm thinking if I am, it is by accident and shouldn't be the case. > JAWS is for pre-2.0, right? Can you shed light on this? > You do not need to set the persistence-manager; all you need to do is specify the correct doctype in the ejb-jar.xml file. Do you have the following in your ejb-jar.xml file: http://java.sun.com/j2ee/dtd/ejb-jar_2_0.dtd";> If not added it. Are you coding CMP 2.0 beans? For example, is the entity bean class abstract? If not, you need to convert your code to CMP 2.0. When you run you application you should not ANY messages from JAWS. -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
> 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. Yes, I have run into the same issue using a custom finder. One finder in particular returns all order lines for a customer. This is very quick if a moderate amount of records, but because agonizingly slow when it gets into the hundreds. The custom finder SQL is tuned and tested so I know the PK values are coming back quickly (single column PK). I was thinking of doing some timing tests to see where the issue is. Sounds like you have already done this. I wonder though what the time is to load a bean found by PK rather than the finder collection is. It shouldn't be different, but if it is then that would give us more information. I know other beans that I find by PK load up much faster than 100ms. I am still on 3.0.0beta, but we seem to have the same issue anyway. ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
> Wait. Are you using JAWS? I only ask that because all of the log stuff > is from JAWS. > > If you are using JAWS, I can't help, because I don't know anything about > the JAWS optimized loading process. > > -dain Well, I'm using 3.0 as distributed. I assumed if I set cmp-version to "2.x" that I would be using the persistence-manager for Standard CMP 2.x EntityBean, which in standardjboss.xml is orgJDBCStoreManager. So, to answer your question as best I can, I don't think so and I'm thinking if I am, it is by accident and shouldn't be the case. JAWS is for pre-2.0, right? Can you shed light on this? Frank > Frank Morton wrote: > > >>Dain wrote: > >>BTW: there is a difference between doesn't work and is not fast enough > >>for me. > >> > > > > You are right about that. With all the weird things I have tried on this, > > I have never gotten an exception that I didn't cause which is a real > > testimony to the stability of 3.0.0.RC1. > > > > > >>Have you looked at the server.log? What queries are being executed? > >>Don't post the whole file. Give us a summary. > >> > > > > Here is the log where I invoke the stateless session bean that first > > does a find on a Container, then finds a Collection of Attribute > > beans. I'm after the "name" property in each Attribute. It is doing > > individual selects on each Attribute in the Collection. I guess my > > bottom-line question is if cmp can be coaxed into loading the > > Collection with a single Select since it takes around 100ms > > per select, leading to about 20 seconds for a Collection of 200. > > > > I'll try any idea you may have. Wow does that leave me open > > for comment ;-) > > > > Frank > > > > 2002-04-24 10:02:37,151 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > > [1] getProfileHandle() > > 2002-04-24 10:02:37,153 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > > [1] getId() > > 2002-04-24 10:02:37,154 DEBUG [org.jboss.jetty.util.NaiveTimeOutManager] > > background thread started: org.jboss.jetty.util.NaiveTimeOutManager@7b914d > > 2002-04-24 10:02:37,248 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > > [1] getId() > > 2002-04-24 10:02:37,311 DEBUG [org.jboss.ejb.plugins.LogInterceptor] > > InvokeHome: create() > > 2002-04-24 10:02:37,318 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > > findByPrimaryKeyMap(1004976,name) > > 2002-04-24 10:02:37,379 DEBUG [org.jboss.ejb.plugins.LogInterceptor] > > InvokeHome: findByPrimaryKey(1004976) > > 2002-04-24 10:02:37,383 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > > Exists command executing: SELECT COUNT(*) FROM Container WHERE id=? > > 2002-04-24 10:02:37,383 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > > Set parameter: idx=1, jdbcType=BIGINT, value=1004976 > > 2002-04-24 10:02:37,387 DEBUG [org.jboss.jetty.util.NaiveTimeOutManager] > > background thread ended: org.jboss.jetty.util.NaiveTimeOutManager@7b914d > > 2002-04-24 10:02:37,420 DEBUG [org.jboss.ejb.plugins.LogInterceptor] > > InvokeHome: findByContainerId(1004976) > > 2002-04-24 10:02:37,423 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > > findByContainerId command executing: SELECT id FROM Attribute WHERE > > containerId=? > > 2002-04-24 10:02:37,423 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > > Set parameter: idx=1, jdbcType=BIGINT, value=1004976 > > 2002-04-24 10:02:37,555 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > > [1006166] getName() > > 2002-04-24 10:02:37,556 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > > Load command executing: SELECT > > Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. > > containerType FROM Attribute WHERE id=? > > 2002-04-24 10:02:37,556 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > > Set parameter: idx=1, jdbcType=BIGINT, value=1006166 > > 2002-04-24 10:02:37,623 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > > [1006167] getName() > > 2002-04-24 10:02:37,624 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > > Load command executing: SELECT > > Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. > > containerType FROM Attribute WHERE id=? > > 2002-04-24 10:02:37,625 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > > Set parameter: idx=1, jdbcType=BIGINT, value=1006167 > > 2002-04-24 10:02:37,685 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > > [1006168] getName() > > 2002-04-24 10:02:37,688 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > > Load command executing: SELECT > > Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. > > containerType FROM Attribute WHERE id=? > > 2002-04-24 10:02:37,689 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > > Set parameter: idx=1, jdbcType=BIGINT, value=1006168 > > 2002-04-24 10:02:37,768 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > > [1007007] getName() > > 2002-04-24 10:02:37,771 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > > Load command executing:
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
Wait. Are you using JAWS? I only ask that because all of the log stuff is from JAWS. If you are using JAWS, I can't help, because I don't know anything about the JAWS optimized loading process. -dain Frank Morton wrote: >>Dain wrote: >>BTW: there is a difference between doesn't work and is not fast enough >>for me. >> > > You are right about that. With all the weird things I have tried on this, > I have never gotten an exception that I didn't cause which is a real > testimony to the stability of 3.0.0.RC1. > > >>Have you looked at the server.log? What queries are being executed? >>Don't post the whole file. Give us a summary. >> > > Here is the log where I invoke the stateless session bean that first > does a find on a Container, then finds a Collection of Attribute > beans. I'm after the "name" property in each Attribute. It is doing > individual selects on each Attribute in the Collection. I guess my > bottom-line question is if cmp can be coaxed into loading the > Collection with a single Select since it takes around 100ms > per select, leading to about 20 seconds for a Collection of 200. > > I'll try any idea you may have. Wow does that leave me open > for comment ;-) > > Frank > > 2002-04-24 10:02:37,151 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > [1] getProfileHandle() > 2002-04-24 10:02:37,153 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > [1] getId() > 2002-04-24 10:02:37,154 DEBUG [org.jboss.jetty.util.NaiveTimeOutManager] > background thread started: org.jboss.jetty.util.NaiveTimeOutManager@7b914d > 2002-04-24 10:02:37,248 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > [1] getId() > 2002-04-24 10:02:37,311 DEBUG [org.jboss.ejb.plugins.LogInterceptor] > InvokeHome: create() > 2002-04-24 10:02:37,318 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > findByPrimaryKeyMap(1004976,name) > 2002-04-24 10:02:37,379 DEBUG [org.jboss.ejb.plugins.LogInterceptor] > InvokeHome: findByPrimaryKey(1004976) > 2002-04-24 10:02:37,383 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > Exists command executing: SELECT COUNT(*) FROM Container WHERE id=? > 2002-04-24 10:02:37,383 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > Set parameter: idx=1, jdbcType=BIGINT, value=1004976 > 2002-04-24 10:02:37,387 DEBUG [org.jboss.jetty.util.NaiveTimeOutManager] > background thread ended: org.jboss.jetty.util.NaiveTimeOutManager@7b914d > 2002-04-24 10:02:37,420 DEBUG [org.jboss.ejb.plugins.LogInterceptor] > InvokeHome: findByContainerId(1004976) > 2002-04-24 10:02:37,423 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > findByContainerId command executing: SELECT id FROM Attribute WHERE > containerId=? > 2002-04-24 10:02:37,423 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > Set parameter: idx=1, jdbcType=BIGINT, value=1004976 > 2002-04-24 10:02:37,555 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > [1006166] getName() > 2002-04-24 10:02:37,556 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > Load command executing: SELECT > Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. > containerType FROM Attribute WHERE id=? > 2002-04-24 10:02:37,556 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > Set parameter: idx=1, jdbcType=BIGINT, value=1006166 > 2002-04-24 10:02:37,623 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > [1006167] getName() > 2002-04-24 10:02:37,624 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > Load command executing: SELECT > Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. > containerType FROM Attribute WHERE id=? > 2002-04-24 10:02:37,625 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > Set parameter: idx=1, jdbcType=BIGINT, value=1006167 > 2002-04-24 10:02:37,685 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > [1006168] getName() > 2002-04-24 10:02:37,688 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > Load command executing: SELECT > Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. > containerType FROM Attribute WHERE id=? > 2002-04-24 10:02:37,689 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > Set parameter: idx=1, jdbcType=BIGINT, value=1006168 > 2002-04-24 10:02:37,768 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > [1007007] getName() > 2002-04-24 10:02:37,771 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > Load command executing: SELECT > Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. > containerType FROM Attribute WHERE id=? > 2002-04-24 10:02:37,771 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > Set parameter: idx=1, jdbcType=BIGINT, value=1007007 > 2002-04-24 10:02:37,839 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: > [1007008] getName() > 2002-04-24 10:02:37,840 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] > Load command executing: SELECT > Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. > containerType FROM At
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
> Dain wrote: > BTW: there is a difference between doesn't work and is not fast enough > for me. You are right about that. With all the weird things I have tried on this, I have never gotten an exception that I didn't cause which is a real testimony to the stability of 3.0.0.RC1. > Have you looked at the server.log? What queries are being executed? > Don't post the whole file. Give us a summary. Here is the log where I invoke the stateless session bean that first does a find on a Container, then finds a Collection of Attribute beans. I'm after the "name" property in each Attribute. It is doing individual selects on each Attribute in the Collection. I guess my bottom-line question is if cmp can be coaxed into loading the Collection with a single Select since it takes around 100ms per select, leading to about 20 seconds for a Collection of 200. I'll try any idea you may have. Wow does that leave me open for comment ;-) Frank 2002-04-24 10:02:37,151 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: [1] getProfileHandle() 2002-04-24 10:02:37,153 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: [1] getId() 2002-04-24 10:02:37,154 DEBUG [org.jboss.jetty.util.NaiveTimeOutManager] background thread started: org.jboss.jetty.util.NaiveTimeOutManager@7b914d 2002-04-24 10:02:37,248 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: [1] getId() 2002-04-24 10:02:37,311 DEBUG [org.jboss.ejb.plugins.LogInterceptor] InvokeHome: create() 2002-04-24 10:02:37,318 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: findByPrimaryKeyMap(1004976,name) 2002-04-24 10:02:37,379 DEBUG [org.jboss.ejb.plugins.LogInterceptor] InvokeHome: findByPrimaryKey(1004976) 2002-04-24 10:02:37,383 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Exists command executing: SELECT COUNT(*) FROM Container WHERE id=? 2002-04-24 10:02:37,383 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Set parameter: idx=1, jdbcType=BIGINT, value=1004976 2002-04-24 10:02:37,387 DEBUG [org.jboss.jetty.util.NaiveTimeOutManager] background thread ended: org.jboss.jetty.util.NaiveTimeOutManager@7b914d 2002-04-24 10:02:37,420 DEBUG [org.jboss.ejb.plugins.LogInterceptor] InvokeHome: findByContainerId(1004976) 2002-04-24 10:02:37,423 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] findByContainerId command executing: SELECT id FROM Attribute WHERE containerId=? 2002-04-24 10:02:37,423 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Set parameter: idx=1, jdbcType=BIGINT, value=1004976 2002-04-24 10:02:37,555 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: [1006166] getName() 2002-04-24 10:02:37,556 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Load command executing: SELECT Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. containerType FROM Attribute WHERE id=? 2002-04-24 10:02:37,556 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Set parameter: idx=1, jdbcType=BIGINT, value=1006166 2002-04-24 10:02:37,623 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: [1006167] getName() 2002-04-24 10:02:37,624 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Load command executing: SELECT Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. containerType FROM Attribute WHERE id=? 2002-04-24 10:02:37,625 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Set parameter: idx=1, jdbcType=BIGINT, value=1006167 2002-04-24 10:02:37,685 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: [1006168] getName() 2002-04-24 10:02:37,688 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Load command executing: SELECT Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. containerType FROM Attribute WHERE id=? 2002-04-24 10:02:37,689 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Set parameter: idx=1, jdbcType=BIGINT, value=1006168 2002-04-24 10:02:37,768 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: [1007007] getName() 2002-04-24 10:02:37,771 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Load command executing: SELECT Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. containerType FROM Attribute WHERE id=? 2002-04-24 10:02:37,771 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Set parameter: idx=1, jdbcType=BIGINT, value=1007007 2002-04-24 10:02:37,839 DEBUG [org.jboss.ejb.plugins.LogInterceptor] Invoke: [1007008] getName() 2002-04-24 10:02:37,840 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Load command executing: SELECT Attribute.id,Attribute.containerId,Attribute.name,Attribute.value,Attribute. containerType FROM Attribute WHERE id=? 2002-04-24 10:02:37,841 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Set parameter: idx=1, jdbcType=BIGINT, value=1007008 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
Frank, I'm assuming you're doing read-only operations? What we typically do is use SQL and just load data-objects ourselves for collections that size. hth dim - Original Message - From: "Frank Morton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 24, 2002 1:44 PM Subject: Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer > 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: > > > > > > > > > > > > Container Session Beans > > Container Session Beans > > > > > > ContainerControl > > > > com.base2inc.bean.session.container.ContainerControlHome > > > > com.base2inc.bean.session.container.ContainerControl > > > > > com.base2inc.bean.session.container.ContainerControlBean > ss> > > 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. > > > > > > > > > > > > AttributeManag
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
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: >> >> >> >> >> >> Container Session Beans >> Container Session Beans >> >> >> ContainerControl >> >>com.base2inc.bean.session.container.ContainerControlHome >> >>com.base2inc.bean.session.container.ContainerControl >> >> > com.base2inc.bean.session.container.ContainerControlBean >>ss> >> 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- &g
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
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: > > > > > > Container Session Beans > Container Session Beans > > > ContainerControl > > com.base2inc.bean.session.container.ContainerControlHome > > com.base2inc.bean.session.container.ContainerControl > > com.base2inc.bean.session.container.ContainerControlBean ss> > 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. Yo
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
Marius Kotsbak wrote: > I remember from using jboss 2.4.x, that manual changes in the DB would > take some time to be reflected from CMP-beans (no new data even in a new > transaction after the change), probably because jboss was caching the > data, and not writing it to the DB at the same time the set-method was > called. No, it was because JBoss 2.4 used commit option A by default and in JBoss 3.0 we switched to B. If you want to know about commit options read the EJB spec. > With jboss 3.x, I don't see this behavior. What has happened, > what is the difference? Is there no write-cache now? Does it save one > and one property of the beans? What? Writes are delayed until the end of the transaction, if that is what you mean, but that is not really a cache. > There should be a doc of the CMP-engine to answer these FAQs, at least a > updated description of the settings in the DTD (the comments there > doesn't explain it very well) I am literally writing this chapter right now in another window. -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
Dain Sundstrom wrote: > Marius Kotsbak wrote: > >> In that file, I find false. Is there >> a reason for that to be false as default? > > > > FK constraints are not supported by hypersonic, or more importantly I > couldn't get them to work. > > >> And since this one is there: >> >> on-load >> 1000 >> * >> >> 1000 >> >> , shouldn't most uses of CMPs be tuned OK (when using the same >> transaction!)? > > > > what? > > >> What does , and 300 mean? > > > > list cache max is the number of queries that the container will remember. > When a query is executed, JBossCMP remembers the order of the > results. When lazy loading the container will read-ahead the next n > entities from the list. > > time-out has been renamed to read-time-out, and specifies the amount > of time that a read-only field is considered valid (milliseconds). I remember from using jboss 2.4.x, that manual changes in the DB would take some time to be reflected from CMP-beans (no new data even in a new transaction after the change), probably because jboss was caching the data, and not writing it to the DB at the same time the set-method was called. With jboss 3.x, I don't see this behavior. What has happened, what is the difference? Is there no write-cache now? Does it save one and one property of the beans? There should be a doc of the CMP-engine to answer these FAQs, at least a updated description of the settings in the DTD (the comments there doesn't explain it very well) > > -dain > > > > ___ > 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: [JBoss-user] CMP: Iterate Collection Performance Killer
Marius Kotsbak wrote: > In that file, I find false. Is there a > reason for that to be false as default? FK constraints are not supported by hypersonic, or more importantly I couldn't get them to work. > And since this one is there: > > on-load > 1000 > * > > 1000 > > , shouldn't most uses of CMPs be tuned OK (when using the same > transaction!)? what? > What does , and 300 mean? list cache max is the number of queries that the container will remember. When a query is executed, JBossCMP remembers the order of the results. When lazy loading the container will read-ahead the next n entities from the list. time-out has been renamed to read-time-out, and specifies the amount of time that a read-only field is considered valid (milliseconds). -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
Dain Sundstrom wrote: > danch wrote: > >> Dain Sundstrom wrote: >> >>> Frank Morton wrote:> >>> 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. >>> >>> >>> >>> >>> >>> That won't work. It shouldn't even boot. Check the dtd. >> >> >> >> >> ? standardjaws.xml is just ignored in jboss3, i'n'it? >> > > > Ya, didn't read to close. > > Change standardjbosscmp-jdbc.xml instead. > > -dain > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user In that file, I find false. Is there a reason for that to be false as default? And since this one is there: on-load 1000 * 1000 , shouldn't most uses of CMPs be tuned OK (when using the same transaction!)? What does , and 300 mean? Marius K Boostcom.no ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
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.ContainerControlBean 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 > &g
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
danch wrote: > Dain Sundstrom wrote: > >> Frank Morton wrote:> >> >>> 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. >> >> >> >> >> That won't work. It shouldn't even boot. Check the dtd. > > > > ? standardjaws.xml is just ignored in jboss3, i'n'it? > Ya, didn't read to close. Change standardjbosscmp-jdbc.xml instead. -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
Dain Sundstrom wrote: > Frank Morton wrote:> >> 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. > > > > That won't work. It shouldn't even boot. Check the dtd. ? standardjaws.xml is just ignored in jboss3, i'n'it? -danch ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
Frank Morton wrote: >>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? No, it is just one of the two (good) options. > 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. That won't work. It shouldn't even boot. Check the dtd. > Seems no matter what I do, I get the > same behavior, so I must be missing something. Start a transaction, do your work, commit the transaction. > 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. Depends where this code is. If it is in an EJB, just set the method to Required. If it is in a web app, lookup the user transaction in jndi, start it, and commit it. Try the book at theserverside.com, or search google for "ejb user transaction". > Thanks. I'm guessing I'm not the only one that needs to know about this. You are about the 10th this week. We need a FAQ, but I'm to busy to write it, so I'm not allowed to complain. -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
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 com.base2inc.bean.entity.attribute.AttributeHome com.base2inc.bean.entity.attribute.Attribute com.base2inc.bean.entity.attribute.AttributeBean Container java.lang.Long False 2.x idBIGINT containerIdBIGINT containerType name value id on-load 255 1000 Attribute * Required 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? > > > > TIA. > > > > > > ___ > > 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: [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 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? > > TIA. > > > ___ > 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: [JBoss-user] CMP: Iterate Collection Performance Killer
I'm not sure of all the details, but you want to use cmp2 and investigate the read-ahead stuff Dain implemented. Also you need to make sure your transactions are large enough to include all the access to the whole collection. david jencks On 2002.04.23 11:08:10 -0400 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? > > TIA. > > > ___ > 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] CMP: Iterate Collection Performance Killer
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? TIA. ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
