Hmmm, that's not going to be a particularly useful test for measuring
threading effects.
Mostly because you're operating way out of the "normal" range of a IN
query, which means that H2 is not likely to be generating particularly
good query plans.
As to the docs - yes, queries do block each other.
However, only the lower layers of our storage engine are running under a
single database-wide lock.
Most of the upper layers run under a connection-specific lock, which
means that multiple connections manage to exhibit quite a bit of
concurrency.
On 2013-10-06 06:29, Brian Craft wrote:
Reading over the archive on the subject of threads has left me mostly
still confused about how h2 handles concurrency, so I've been doing
some tests, instead.
I started with largish queries that all have a "where ... in" clause
with 500 values (like "where x in [v0, v1, v2, .... v499]"), which ran
with average time 120 seconds.
I then re-ran the same queries as sets of 500 queries (each with a
single value, like "where x in [v0]"), splitting the queries across
different threads. These sets of 500 queries ran much faster, average
30 seconds. It also made much more use of the disk: io stats where
much higher, which is consistent with the queries running concurrently.
The docs seem to indicate that a query in one thread blocks queries in
other threads, so I'm not sure how to interpret these numbers. Maybe I
misunderstood the docs, and queries do run concurrently? I'm not using
MULTI_THREADED.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
