Ok, some additional, even better info<br><br>H2 has an in-memory mode, test time reduces from an average of 2 minutes to almost 1 minute, same test fails, a lot quicker since there is a stack-overflow instead of a deadlock timeout<br>
<br>But.... I saw a parameter MVCC that I recognized from the ESB config. Turning that param on, makes ALL tests run, really... ALL tests.The Deadlock timeouts had a major influence on the test time. With persistency it is now 1.20 seconds...<br>
<br>Ronald <br><br><br><div class="gmail_quote">On Mon, Dec 15, 2008 at 10:57 PM, Ronald van Kuijk <span dir="ltr"><<a href="mailto:ronald@jbpm.org">ronald@jbpm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Guys,<br><br>Considering all the trouble there continuously is with HSQLDB, I gave it a shot to try and embed H2 in jBPM. The of my time was figuring out where the <beep> all parts of the ddl/config generation was put and how to create a new profile. Eventually when the tests were run, only one failed in the core, the JobExecutorTest with multiple threads. H2 gave a deadlock error there, but that might be because of tuning, I'll try to figure that one out yet. It only took H2 in embedded mode 1m45 with file persistency compared to H2 55 seconds in-memory (not sure there is a pure in-memory mode for H2)<br>
<br>The web console for H2 btw is also nice, so for me it is a real replacement for HSQLDB.<br><br>Next is trying to figure out if the enterprise module can be tested the same way... I've seen that the ESB guys run jBPM against H2 (they've created an mbean to start H2 the same way as HSQLDB is started). <br>
<font color="#888888">
<br>Ronald<br>
</font></blockquote></div><br>