Re: [JBoss-user] Extremely slow transaction

[Marius Kotsbak]

Jon Haugsand wrote:

* Sacha Labourey

hello,

Sorry to show up so lately in your discussion but what is the real problem?
I guess it is not the transaction in itself? You seem to say that your
problem comes from the way JBossCMP loads your data, do you have more
information and what is actually happening and why you think it kills your
performance?

Thanks for showing interest. This is a real problem for us. We have
some code that looks loosely like this:

for (id=0;id++;id<1000) {
// Start transaction
Collection c=findByStatus(id,status);
for(i=c.iterator();i.hasNext();) {
((EntityLocal) (i.next())) . setStatus(newStatus);
}
// End transaction
}

From the log/server.log we see that each findByStatus generates a HUGE

select statement with around 300 ORs  ( SELECT id FROM VPKRITERIE
WHERE (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR (id=?) OR
(id=?) ............

We have tried to play around with conf/standardjbosscmp-jdbc.xml and
standardjaws.xml, but to no help.  The parameteres set is:

in  standardjbosscmp-jdbc.xml:

     <read-ahead>
     <strategy>on-find</strategy>
     <eager-load-group>*</eager-load-group>
     </read-ahead>

eager-load group shold list the fields that you are accessing in your transaction, f.ex. status.

in standardjaws.xml:

        <read-ahead>false</read-ahead>

This should probably be true, to have it load more at a time!

We now are in the process to do this on the individual beans, but are
not there yet because it is not supported in xdoclet.
Any suggestions?

Also take a look at the sql that jbosscmp is generating (you might need to include DEBUG-level in log4j).




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user