Hello, I don't know if this is of any relevance but here at 4Production we also have the problem of some code being too slow. Further analysis (as of yesterday) showed that iterating over a findAll() Collection got the server emint a huge (preloading?) sql query for every iteration (call to next()). This wasn't the case under 3.2-beta; it just came to our attention after a cvs update this tuesday. We are not sure if the problems was already in 3.3-beta, because we only use such iterations in a very small part of our code and our production machine is really fast. And we have not eliminated problems on our side, but as the transaction markup should dictate (all of it in "REQUIRED" methods) everything should run under one transaction. We have Adrian (who is our official supporter) told about our problems.
Just my 2c, Michael Bartmann Sacha Labourey wrote: >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? > >Thank you. Cheers, > > > > Sacha > > > >>-----Message d'origine----- >>De : [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]]De la part de Jon >>Haugsand >>Envoye : vendredi, 11 octobre 2002 08:47 >>A : [EMAIL PROTECTED] >>Objet : Re: [JBoss-user] Extremely slow transaction >> >> >>* Marius Kotsbak >> >> >>>>>>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 >>>>>>} >>>>>> >>>>>> >>>>>> >>>>>Why not package the whole in one transaction (including the outher >>>>>for-statement), too see if this speeds things up, if it >>>>> >>>>> >>doesn't change >> >> >>>>>the semantics of your operation. Or you might start a nested >>>>>transaction for the inner for. >>>>> >>>>> >>>>We can try this in order to see the effect, but we cannot change this >>>>permanently. >>>> >>>> >>>Why not? >>> >>> >>Several reasons: >> >> 1. The transaction will take too long time, locking other requests >> out. >> 2. An exception would roll back all updates to the entity bean >> instances. >> >>Of course, no 2 can be solved by designing differently, but that is >>also a risk in our project. No 1 has to be tested. >> >>-- >> Jon Haugsand, <[EMAIL PROTECTED]> >> Norges Bank, <http://www.norges-bank.no> >> >> >> >>------------------------------------------------------- >>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 >> >> >> > > > >------------------------------------------------------- >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 > > > ------------------------------------------------------- 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
