jdbc:h2:mem: threadsafe?

1,071 views
Skip to first unread message

Laird Nelson

unread,
Oct 7, 2013, 5:41:21 PM10/7/13
to h2-da...@googlegroups.com
The documentation says that connecting to the JDBC URL "jdbc:h2:mem:" creates a "private" in-memory database.

Is the database so created private to the thread that creates it?

If threads t1 and t2 both attach to jdbc:h2:mem:, do they or do they not share the database?  I hope that it is intended that they do not.

Best,
Laird

Laird Nelson

unread,
Oct 7, 2013, 5:46:56 PM10/7/13
to h2-da...@googlegroups.com
On Monday, October 7, 2013 2:41:21 PM UTC-7, Laird Nelson wrote:
The documentation says that connecting to the JDBC URL "jdbc:h2:mem:" creates a "private" in-memory database.

Is the database so created private to the thread that creates it?

To be clear, I'm aware of this documentation paragraph as well:

"In some cases, only one connection to a in-memory database is required. This means the database to be opened is private. In this case, the database URL is jdbc:h2:mem: Opening two connections within the same virtual machine means opening two different (private) databases."

I just want to make sure that two connections in two threads in the same VM each get a database scoped to that thread.

Best,
Laird 

Thomas Mueller

unread,
Oct 8, 2013, 1:24:12 PM10/8/13
to h2-da...@googlegroups.com
Hi,

I think the documentation is quite clear.

Of course in Java, you can pass around objects to any thread you like. If your application has a handle on an object, you can also call methods on it concurrently in multiple threads. H2 is thread-safe (as documented), but there are parts of the JDBC API that are problematic, for example it doesn't make sense to call PreparedStatement.setString + execute concurrently on the same object. But that has nothing to do with H2.

Regards,
Thomas

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

Laird Nelson

unread,
Dec 30, 2013, 6:50:26 PM12/30/13
to h2-da...@googlegroups.com
On Tuesday, October 8, 2013 10:24:12 AM UTC-7, Thomas Mueller wrote:
I think the documentation is quite clear.

Let me rephrase the question (and sorry for just now noticing the timely reply):

Suppose I have two threads, t1 and t2.  Suppose each of them opens a connection to jdbc:h2:mem:  Suppose that each of them now issues a CREATE TABLE Fred statement.  Suppose further that each of them now inserts one row into the Fred table.

If t1 then issues a SELECT COUNT(*) FROM Fred, and if no other database activity takes place, will the result be guaranteed to be 1?  Or will it be 2?

Thanks,
Best,
Laird

Ryan How

unread,
Dec 30, 2013, 8:38:46 PM12/30/13
to h2-da...@googlegroups.com
It will be 2. and the second create table will fail because the table already exists. But I don't see how that has anything to do with being thread safe? The in memory database is per process, so all threads access the same database. If you want a separate database per thread then give the databases different names.

Laird Nelson

unread,
Jan 2, 2014, 2:53:05 PM1/2/14
to h2-da...@googlegroups.com
On Monday, December 30, 2013 5:38:46 PM UTC-8, Kartweel wrote:
It will be 2.

Thanks.
 
and the second create table will fail because the table already exists.

Yep; thanks.
 
But I don't see how that has anything to do with being thread safe?

I'm sure I worded it badly.  I am trying to see how best to run parallel unit tests using the maven-surefire-plugin, where you can control parallelism at the process and thread level.  I didn't see anything in the H2 documentation about whether a "mem" database was one-per-process or one-per-thread.
 
The in memory database is per process, so all threads access the same database.

Thank you; this is what I was looking for.  Is there a spot in the documentation that says this explicitly?
 
If you want a separate database per thread then give the databases different names.

That has been my approach so far; it dawned on me (wrongly, as it turns out) that perhaps I was overengineering something—that perhaps jdbc:h2:mem was enough for a private per-thread database, but as you point out it is not.  Thanks for your time and the clarity of your response.

Best,
Laird

--

Thomas Mueller

unread,
Jan 3, 2014, 3:34:08 AM1/3/14
to H2 Google Group
Hi,

a private per-thread database

There is nothing like a "per-thread database". My guess is what you mean is "in-memory private".

Each time you open a connection using the exact database URL "jdbc:h2:mem:", you will get a new database ("in-memory private"). It doesn't matter if that's within the same process or thread or not.

Each time you open a connection using the database URL "jdbc:h2:mem:test" or similar (that is, something after "mem:"), you will get _the same_ database within the same classloader if you use the same name. This again doesn't depend on the thread.

For details, see: 

Regards,
Thomas



--
Reply all
Reply to author
Forward
0 new messages