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
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
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
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
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
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,
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
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
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
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
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
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
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
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
14 matches
Mail list logo
