Since this hibernate HHH-7689 issue has been fixed I have been able to use an internal benchmark. The benchmark uses jdbc batching to prepare initial data for a benchmark run with a relational database like PostgreSQL.
Depending on the environment I use the loading of data takes different amounts of time. I am seeing a problem on "slow" hardware. ie my local laptop and desktop versus dedicated servers.
What I am seeing is the loading of data fail. Loading the data takes a while so the Recovery Manager rightly detects a timeout and aborts the transaction. Using the default of 300 seconds.
To get round this I've attempted two things. By setting the default-timeout attribute on the coordinator-environment element in the server configuration file.
a) Set a adequately high timeout (in seconds). e.g. 1200 (an hour)
b) disable the timeout. Using -1
In both situations I find the Recovery Manager does not do what I am expecting. Which is avoid timing out the long running transaction sufficiently long enough for the data to load.
To demonstrate test case a) is attached a Wildfly 8.1 server log file. With TRACE logging enabled for "com.arjuna.ats.arjuna" category. The data loading was initiated after the server completed the start-up sequence. This demonstrates the recovery manager aborting the transaction at 10:34:10,274 after 694 seconds (11 minutes 34).
I wonder if the tx is being marked abort for other reasons. Is there a different category I can use to show this ?
4.3.1.Final Wildfly 8.1.0.Final
4.2.14.Final in EAP 6.3.0.Beta
Using PostgreSQL 9.2.8.
$ java -version
java version "1.7.0_65"
OpenJDK Runtime Environment (fedora-18.104.22.168.fc19-x86_64 u65-b17)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
$ uname -a
Linux burtha02-f19 3.14.13-100.fc19.x86_64 #1 SMP Fri Jul 18 02:36:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
server.log.zip 19.1 KB