Hi Falko, A couple of comments,
1) I would recommend using the Hibernated-based persistence code; AFAIK nobody has done any performance/load testing on the OpenJPA-based persistence DAOs. 2) Looks like you're using MySQL, so make sure you're using the InnoDB engine since Ode requires transaction support and multi-version concurrency-control (MVCC). 3) I don't see evidence of the "database being in an inconsistent state" if you mean that in the data corruption sense. What I see is the system into a state where transactions repeatedly fail, apparently because the connections become invalid. This is a transaction manager issue, so it is dependent on the quality and robustness of your appserver/container (in this case the combination of ServiceMix + Geronimo's TM + Enhydra connection pool). alex On 1/29/08, Falko Menge <[EMAIL PROTECTED]> wrote: > > Hello everyone, > > I'm currently working on a research project trying to improve scalability > ofthe bleeding edge > workflow engines by distributing processes across multiple systems. For > the > empirical validation of the approach I wanted to use ODE deployed in > ServiceMix. > Unfortunately, during the first stress tests with ODE it turned out, that > requests arriving nearly simultaneously seem to cause deadlocks of the > database > transactions. > > soupUI's load testing feature was used to produce the requests. In ODE 1.0and > 1.1 it was enough to use only two threads each sending a single request to > immediately produce errors like this: > > ERROR 40XL1: A lock could not be obtained within the time requested > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > ... > After that, the database seems to be in an inconsistent state, which leads > to a > complete denial of service. > > I made tests with all examples in the JBI release as well as own > processes, > using different ServiceMix and ODE Versions under Windows and Linux. > Furthermore I tried MySQL, which also produced similar problems: > > connectionErrorOccurred called with null > java.sql.SQLException: Lock wait timeout exceeded; try restarting > transaction > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:946) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2985) > ... > > In ODE 1.1.1 it seems to have improved a bit. But if the number of threads > is > increased, the problem occurs again. Currently, I in-memory processes as a > workaround, but that is of course not a realistic scenario for production > systems. > > Has anyone experienced similar problems? I would appreciate every help to > make > my experiments with persistent processes. I attached two logfiles > containing > complete stack traces and I could also provide more data from my extensive > series of tests. > > Greetings from Berlin > Falko >
