Home/ Questions/Q 7739441
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T08:31:27+00:00

This is related to this post . I think I am having problem with

  • 0

This is related to this post.
I think I am having problem with H2 meaning that it does not close properly.
I suspect this since I see myDB.lock.db when I shutdown tomcat and the process does not stop.
I use Tomcat’s connection pooling and the url to the database is:
url="jdbc:h2:file:/opt/myOrg/tomcat/webapps/MyApplication/db/myDatabase;SCHEMA=myschema"

From the doc close H2:

Usually, a database is closed when the last connection to it is
closed…. By default, a database is closed when the last connection
is closed. However, if it is never closed, the database is closed when
the virtual machine exits normally, using a shutdown hook

I can not understand if I am doing something wrong.
Should I be forcing the database to close via a command? Is this the meaning of shutdown hook?
What am I doing wrong here?

Note:
I can not find in Google an example of how to close H2 properly (besides the statement that it closes automatically on last connection shutdown). Should I call SHUTDOWN myself? Is this the proper approach?
I already see votes to close the question but there has not been a reason or link on an example of what I am investigating

UPDATE:
After Joonas Pulakka answer some extra info:

From the javacore I got using a kill -3 I see the threads:

“H2 Log Writer MYAPPLICATION” J9VMThread:0x08DC6F00,
j9thread_t:0x08C9B790, java/lang/Thread:0xE7206CC8, state:CW, prio=5
3XMTHREADINFO1 (native thread ID:0xA32, native
priority:0x5, native policy:UNKNOWN) 3XMTHREADINFO2
(native stack address range from:0xE5E26000, to:0xE5E67000,
size:0x41000) 3XMTHREADINFO3 Java callstack:
4XESTACKTRACE at java/lang/Object.wait(Native Method)
4XESTACKTRACE at
java/lang/Object.wait(Object.java:196(Compiled Code)) 4XESTACKTRACE
at org/h2/store/WriterThread.run(WriterThread.java:102)
4XESTACKTRACE at java/lang/Thread.run(Thread.java:736)

3XMTHREADINFO “pool-8-thread-1” J9VMThread:0x087C0200,
j9thread_t:0x0840566C, java/lang/Thread:0xE79BFC80, state:P, prio=5
3XMTHREADINFO1 (native thread ID:0xE1A, native
priority:0x5, native policy:UNKNOWN) 3XMTHREADINFO2
(native stack address range from:0xE5F69000, to:0xE5FAA000,
size:0x41000) 3XMTHREADINFO3 Java callstack:
4XESTACKTRACE at sun/misc/Unsafe.park(Native Method)
4XESTACKTRACE at
java/util/concurrent/locks/LockSupport.park(LockSupport.java:184(Compiled
Code)) 4XESTACKTRACE at
java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1998(Compiled
Code)) 4XESTACKTRACE at
java/util/concurrent/LinkedBlockingQueue.take(LinkedBlockingQueue.java:413(Compiled
Code)) 4XESTACKTRACE at
java/util/concurrent/ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:958(Compiled
Code)) 4XESTACKTRACE at
java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
4XESTACKTRACE at java/lang/Thread.run(Thread.java:736)

3XMTHREADINFO “H2 File Lock Watchdog
opt/myOrg/tomcat/webapps/MyApplication/db/myDatabase.lock.db”
J9VMThread:0x08DC6900, j9thread_t:0x08C9BA24, ja
va/lang/Thread:0xE71E9018, state:CW, prio=9 3XMTHREADINFO1
(native thread ID:0xA30, native priority:0x9, native policy:UNKNOWN)
3XMTHREADINFO2 (native stack address range from:0xE5DBA000,
to:0xE5DFB000, size:0x41000) 3XMTHREADINFO3 Java
callstack: 4XESTACKTRACE at
java/lang/Thread.sleep(Native Method) 4XESTACKTRACE
at java/lang/Thread.sleep(Thread.java:851(Compiled Code))
4XESTACKTRACE at
org/h2/store/FileLock.run(FileLock.java:490) 4XESTACKTRACE
at java/lang/Thread.run(Thread.java:736)

3XMTHREADINFO “FileWatchdog” J9VMThread:0x087C0800,
j9thread_t:0x08C9B4FC, java/lang/Thread:0xE715D878, state:CW, prio=5
3XMTHREADINFO1 (native thread ID:0xA2C, native
priority:0x5, native policy:UNKNOWN) 3XMTHREADINFO2
(native stack address range from:0xE5E67000, to:0xE5EA8000,
size:0x41000) 3XMTHREADINFO3 Java callstack:
4XESTACKTRACE at java/lang/Thread.sleep(Native Method)
4XESTACKTRACE at
java/lang/Thread.sleep(Thread.java:851(Compiled Code)) 4XESTACKTRACE
at org/apache/log4j/helpers/FileWatchdog.run(FileWatchdog.java:104)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The documentation says that H2 db connection is closed when the virtual machine exits normally. And that’s what it does. The shutdown hook is already there by default, you don’t have to do anything. The shutdown hook is a perfectly valid way of closing resources that only need to be closed when quitting.

    If you have .lock.db files remaining after shutdown, then the virtual machine didn’t exit normally. You wrote that the process does not stop. You have to find the reason for that, because probably that’s what also prevents the H2 shutdown hook from executing.

    With big databases, closing could take some time. See with debugger (e.g. VisualVM) what threads remain active after you’ve invoked (Tomcat) shutdown.

    There’s on more possibility: file permissions are set so that H2 can create the lock files, but cannot delete them. If the OS prevents H2 from deleting its lock files, there’s not much H2 could do about it.

    • 0