Valid point, Donald. I had another look at Derby manual [1] and I think we are quite safe if we also specify derby.locks.deadlockTimeout [2] and make it less than derby.locks.waitTimeout. This should assure we get deadlocks and timeouts as before but faster.
Regards, Milosz [1] http://db.apache.org/derby/docs/10.2/devguide/devguide-single.html#cdevconcepts28436 [2] http://db.apache.org/derby/docs/10.2/tuning/tuning-single.html#rtunproper10607 > The tests may not break, but the results could be completely different > and passing for the wrong reason. > > Seems that we should also set derby.locks.deadlockTrace > http://db.apache.org/derby/docs/10.0/manuals/tuning/perf79.html > and review the trace results, since a lot of the tests just catch an > exception today as the expected test result and don't examine it to > ensure it was the expected type, given a locktimeout will throw a > SQLException. > http://db.apache.org/derby/docs/10.0/manuals/tuning/perf82.html > > > -Donald > > > Miłosz Tylenda wrote: > > Hi All! > > > > Have anybody experimented with setting default Derby timeout in our test > > suite? I have set the timeout to 5 seconds and the test suite execution > > time felt down from 34 to 19 minutes on my system. Part of my > > openjpa-persistence-jdbc pom.xml looks like this: > > > > > > > > openjpa.Log > > DefaultLevel=${openjpa.loglevel} > > > > > > openjpa.ConnectionDriverName > > org.apache.commons.dbcp.BasicDataSource > > > > > > derby.stream.error.file > > target/derby.log > > > > > > derby.locks.waitTimeout > > 5 > > > > > > openjpa.ConnectionProperties > > > > DriverClassName=${connection.driver.name},Url=${connection.url},Username=${connection.username},Password=${connection.password},${dbcp.args} > > > > > > > > We could consider setting this permanently. Hope it will not affect > > timeout-related tests. > > > > Greetings, > > Milosz > > > > >
