Jon Haugsand wrote:
* [EMAIL PROTECTED]
In this case, I miss the sql-statement "UPDATE sometable SET
status=2 WHERE status=6" which I don't think EJB/JBoss-QL can
handle. This will probably speeds things up considerably.
Actually, the code is a bit more complicated, i.e. some computation
for each instance, and the newStatus will vary according to the output
of the tests. It is like a daily update of some records.
Ah. I see. Then it is another case. If it isn't possible to express in a
sql WHRE-clause.
If it is an unsolvable problem, a hack would be to use a sql like
that directly to the DB. You might then perhaps not use all commit
options in jboss safely though (but I think the default for EJB2.x
beans handles this).
Throwing in the towel then? Nooo, I would like to solve the problem
with EJB, at least I won't give up that soon.
Anyway, there are several ways we could live with the slow
transactions. However, I genuinely want to know what is happening and
how to control my application.
Actually, I think we have a problem of the same type too. We have a
transaction that is too long and times out, so we are trying to optimize
that part. Your trick of dividing the transaction might be useful for us
too, or just run under no transaction at all (i think this might be
possible in our case).
You might also optimize a bit by tweaking in jbosscmp-jdbc to fetch multiple entites at a time, and have the status as one load group.
Yes, I think I try this first.
-------------------------------------------------------
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
