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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
