UnknownHostException on SOCKET file lock for filesystem databases

[GoogleCodeExporter]

Before submitting a bug, please check the FAQ:
http://www.h2database.com/html/faq.html

What steps will reproduce the problem?
(simple SQL scripts or simple standalone applications are preferred)
1. Create database structure in code.
2. Set FILE_LOCK to SOCKET.
3. Run on some Linux machines.

What is the expected output? What do you see instead?
Should work just fine, but I get this: http://pastebin.com/X9PhFDBh
This explains why: 
https://github.com/ForgeEssentials/ForgeEssentialsMain/wiki/Hosts-file

What version of the product are you using? On what operating system, file
system, and virtual machine?
Works fine on all Windows machines, and it does work fine on some Linux 
machines.  But others, that may not be set up as well, don't work.  There's 
gotta be some way to code that in H2, instead of having to have users contact 
their hosts to fix it all the time.

Do you know a workaround?
Switching the FILE_LOCK back to FILE, or not using a FILE_LOCK, makes it work 
as expected.

What is your use case, meaning why do you need this feature?
This is while trying to run multiple DB files for a Minecraft mod.  Because 
there's no way to set the host for socket operations with filesystem databases, 
there's nothing we can do on our end.

How important/urgent is the problem for you?
6, on a scale from 1-10

Please provide any additional information below.

Original issue reported on code.google.com by rhydonj@gmail.com on 24 Jan 2013 at 8:27

[GoogleCodeExporter]

Hi,

Sorry I don't understand what the problem is.  You wrote "This explains why" 
but the document at the given link doesn't explain the problem to me.

> There's gotta be some way to code that in H2, instead of having to have users 
contact their hosts to fix it all the time.

Well, could you provide a patch?

Why do you use FILE_LOCK=SOCKET at all (except that it's a documented feature)?

Original comment by thomas.t...@gmail.com on 25 Jan 2013 at 1:26

[GoogleCodeExporter]

The problem is in the localhost portion of the local address method.  Some 
linux distros don't put their localdomain in the hosts file as 127.0.0.1 by 
default, and this is causing the unknown host error.  The "this explains why" 
shows the way the hosts file is when it works and when it doesn't.

I'm using the SOCKET lock because it's crash-proof.  The FILE lock leaves the 
lock file there after a crash, and there's no way to check if something's 
really using the DB with the FILE lock in place.  And I didn't want to leave it 
unlocked because it truly does overwrite changes from another process.  
However, because of this issue, I've had to leave it unlocked anyway.

Original comment by rhydonj@gmail.com on 25 Jan 2013 at 3:28

[GoogleCodeExporter]

In the linked document, the only difference I see is with 127.0.1.1 not with 
127.0.0.1.
127.0.0.1 is localhost in both cases. So no, I don't understand how this links 
shows the problem.

> I'm using the SOCKET lock because it's crash-proof.

What do you mean with crash-proof? The default is also crash-proof in my 
understanding of the word crash-proof.

> The FILE lock leaves the lock file there after a crash, and there's no way to 
check if something's really using the DB with the FILE lock in place.

You can: try to open the database. That's anyway the best way to do it. You 
shouldn't try to dig into the internals of the database anyway. Just use the 
API.

> I've had to leave it unlocked anyway.

If you do, then you are asking for trouble. But you decide of course.

Original comment by thomas.t...@gmail.com on 12 Feb 2013 at 5:56

• Changed state: WorksForMe

[GoogleCodeExporter]

> What do you mean with crash-proof? The default is also crash-proof in my 
understanding of the word crash-proof.

I mean that, in case of a crash, it's possible for the library itself to tell 
that the process that locked the database is no longer running.  With the FILE 
lock, that's not possible.

> You can: try to open the database. That's anyway the best way to do it. You 
shouldn't try to dig into the internals of the database anyway. Just use the 
API.

If I try to open the database after a crash with the FILE lock, it will read 
the lock file there and say the database is open in another process, even 
though it probably isn't, since it crashed.

> In the linked document, the only difference I see is with 127.0.1.1 not with 
127.0.0.1.
127.0.0.1 is localhost in both cases. So no, I don't understand how this links 
shows the problem.

The problem is that localdomain and localhost aren't the same for linux 
distros, like they are for Windows machines, and localdomain is what is needed 
to access some localhost-type functionality on linux.

Meh, whatever, I see it's not possible to express to you, so I'll just have to 
wait the indefinite period until someone on the team experiences the problem.

Original comment by rhydonj@gmail.com on 12 Feb 2013 at 4:30

[GoogleCodeExporter]

> With the FILE lock, that's not possible.

It is, see the docs as 
http://h2database.com/html/advanced.html#file_locking_protocols

The issue tracker is not a discussion forum. Please use StackOverflow or the 
Google Group for questions.

Original comment by thomas.t...@gmail.com on 12 Feb 2013 at 7:11