On 13/06/12 18:16, Simon Helsen wrote:
I have to correct my statement below, I was misreading my own numbers.
The overall write time was about 3 times slower, not just 70%. This is
comparing the latest build, once with and once without transactions
(single user). The numbers (40%) I mentioned before came from 25
concurrent users on a build using transactions from May 15 compared to a
build using transactions from last weekend. That is not quite the same
kind of comparison of course. However, I do recall (I don't have that on
paper) that my own test suite with the May 15 build was running at a
comparable speed whether I was using transactions or not. So I dare to
conclude that write transactions are now considerable more expensive
than around May 15
Is there some way we can turn this into a publicly usable example?
The recent changes to fix problems (JENA-250, JENA-252) might change the
concurrency but the changes also added a potential file system sync the
dataset when transitioning at first use transactionally. Depending on
how you use StoreConenction.release, that might have an effect but in
normal use it's not supposed to (and also syncs should only go to the OS
if they are needed as components keep a flag as to whether a raw update
has been done.
I'm a little surprised that tx and non-tx were the same speed in the
first place.
> by lock contention on the writes
For clarity:
TDB does not use 2-phase locking - it uses a write-behind log.
It does use java locks to protect key datastructures.
Andy
