finder method fails under load

[kamikatze]

Hi!

We are currently evaluating JBoss (3.2.3) for a client (big telco). We've successfully ported one of their applications (about 20 CMP optimistic-locking / CMR / CMT / about 5 SLSBs / Struts) to JBoss using Instance per Transaction 2.0 Scheme.

After some struggle...
-- Found a lot of unnecessary updates when date-fields were involved (Oracle8i DB Scheme) solved with <check-dirty-after-get>false</>
-- had rollbacks which we didn't expect -- solved with move from CMP Standard to Instance per Transaction
...etc.

But after a while the application worked without throwing any exception and it is nearly as responsive as the WL deployment (To be honest, the application was originally optimized for WL and we didn't go that deep into optimization for JBoss)

When we went to load testing, everything went fine until we exceeded 35 concurrent users (Testing done with a JMeter script... login, show all foos, add a foo, show all foos, delete the foo, logout... started one thread per second) but when we try more than 35 users, the findByUserName() method on the user CMP just returns nothing.

Btw. this is not limited by CPU or memory, it's jdk1.4.2_04 64bit on a V480 (4 cpu/ 8 GB) with oracle on a separate box and JMeter on separate boxes. And.. without giving a reason (don't even think there is one), every call to the SLSBs is marked transaction required, even the read only methods.

So my question is: Is there a setting which we might have overseen which controls max-concurrent-transactions or does this scenario blow a whistle in someone's brain who may have experienced something similar?

[kamikatze]

Hi Again!

We were able to push the max parallel user to 50 without having the problem of findByUserName not returning results.
We achieved this by increasing the max number of connections for the pool of the datasource we are using.

This is somewhat odd to me. I understand, that you can not have more than one active transaction per connection. But on the other hand, the CMP Engine should isolate this if running in optimistic locking mode, because then it is not necessary to obtain a row lock, would mean it is not necessary to associate a (java side)transaction to a connection until the (java side)transaction is committed. After that, if the container finds out, that data has changed, it would get a connection and a (db side)transaction to verify that it didn't have stale data in an optimistic locking sense and write back the changes.

Btw. we have <sync-on-commit-only>true</>

So what could be a reason for that behaviour? Any guess?

Thanks in advance, Mika