I'm doing some performance tests with JBoss 2.4.0. In my test, I'm trying to:
1. create (50, 100, 1000) CMP beans using (1, 5, 10) cuncurrent clients.
2. lookup (using findByPrimaryKey method) already created beans using (1, 5, 10) concurrent clients.
3. invoke a getter method on an already created bean using (1, 5, 10) concurrent clients.
Test 2 and 3 succeeds, but Test 1 fails with multiple concurrent clients (transaction deadlock). I've tried out this test with "Required" and "RequiresNew" transactional attribute on the bean.
Please help me in figuring out how to get the Test 1 to work with multiple concurrent clients!
The error stack is as follows:
[EntitySynchronizationInterceptor] Store failed
java.rmi.ServerException: Store failed; nested exception is:
java.sql.SQLException: [ARES]Your transaction (process ID #7) was deadlocked with another process and has been chosen as the deadlock victim. Rerun your transaction.
at com.inet.tds.a.a(Unknown Source)
at com.inet.tds.b.for(Unknown Source)
at com.inet.tds.b.executeUpdate(Unknown Source)
I bet you dollars-to-doughnuts that it has nothing to do with JBoss at all, and everything to do with the combination of your JDBC driver and the SQL database you're using. I just completed a whole battery of tests using a similar scenario to yours with JBoss 2.4.0, JNetDirect's JSQLConnect JDBC driver, and MS SQL Server 7.0 (SP3).
All my BMP entity beans came thru with flying colors, no deadlocks. I'd seen this before in my previous company where we used NAS 4.0. NAS's JDBC drivers did not use to set the TRANSACTION_ISOLATION_LEVEL to NONE on the connection object and that would cause all sorts of problems with multiple threads hitting the same record for SELECTs and UPDATEs. But JSQLConnect does a beautiful job of it and with 40 clients doing simultaneous SELECTs and UPDATEs **AGAINST THE SAME RECORD** there wasn't a single deadlock. Kudos to JSQLConnect and MS SQL Server!
I'd say get a better JDBC driver, or a better SQL DB.
I'm sorry, a bit of bad English there in my last paragraph. NAS 4.0's JDBC drivers WOULD set the TRANSACTION_ISOLATION_LEVEL to NONE and that caused problems. Sorry.
Actually, there is a problem with JBoss 2.4.1. I used Sun's JDBC-ODBC bridge driver with MS SQL Server 2000 enterprise. I ran the same tests (as described above) with JBoss 2.2.2 and JBoss 2.4.1 and while all of my tests succeed with JBoss 2.2.2, they fail with deadlocks with JBoss 2.4.1.
I further found that JBoss 2.4.1 does not handle rollbacks correctly.
To verify my results, I proceeded to write a simple test in which I create an EJB object with default attribute values. I then implemented a setter method on the bean which results in an ArithmeticException (division by zero). My presumption was that this would result in a rollback. With JBoss 2.2.2, this behaves as expected, but with JBoss 2.4.1, the transaction manager throws an exception on rollback. I'm preparing to send the program and the results as a bug report.
In your reply, you said that all your BMP beans worked fine. How about CMP beans?
Your stack trace shows you using the org.opentools.minerva package which is not part of jboss after 2.2.2. Try removing it from your installation and using the classes in jbosspool, org.jboss.pool.(same stuff). The manual in cvs has some example setups with the new class names, although I wasn't able to test them. Don't know if its on the website yet.
The JBoss manual clearly states that it does NOT work with Sun's JDBC-ODBC bridge. You may get it to work with certain functionality, but don't expect it to behave with production quality performance. As soon as I saw that in the manual I saved myself tons of work and downloaded a commercial JDBC driver product, like the one I mentioned in my previous post. Like I said earlier, get a better driver!
...and yes, CMP worked just fine as far as I could tell. I only ran the CMP examples that came with JBoss 2.4.0 copy that I downloaded and those worked fine.