#1751 Row-store lock changed to fair after 2.5.0 - fairness probably could be made configurable

[Almonas Glamba]

Hello,

there a substantial throughput regression to the row-store lock switching from unfair to fair locking after 2.5.0.

In org.hsqldb.persist.RowStoreAVLMemory (and RowStoreAVLDisk) the construction changed in 2.5.1 from:

lock = new ReentrantReadWriteLock();
to:
lock = new ReentrantReadWriteLock(true);

My use case is an in-memory database (MVCC) with one writer thread and many concurrent reader sessions (originally Java 11 / Linux). After moving past 2.5.0 I saw reader throughput collapse under load, with threads spending most of their time parked; reverting to 2.5.0 restored it.

I have isolated the cause with two small benchmarks.

1. DB Benchmark as gradle project:

Unfair:
gradle run -PhsqldbVersion=2.5.0 --args="engine=hsqldb threads=32 duration=5"
Fair:
gradle run -PhsqldbVersion=2.5.1 --args="engine=hsqldb threads=32 duration=5"
gradle run -PhsqldbVersion=2.7.4 --args="engine=hsqldb threads=32 duration=5"

1. A pure-JDK microbenchmark using only ReentrantReadWriteLock (a single boolean difference, no HSQLDB code).

Attached as single file, can be run without arguments.

Would it be possible to make the lock fairness configurable, e.g. via a system property or a database setting, so deployments can opt back into unfair locking where throughput matters more than acquisition ordering?

I appreciate there may have been a reason for the change (writer starvation / fairness), so an opt-in/opt-out would let both use cases be served.

Happy to share the benchmark and full results if helpful. Thanks for HSQLDB.

Best Regards,
Almonas