什么是关闭H2的正确方法？ [英] What is the proper way to close H2?

查看：319
本文介绍了什么是关闭H2的正确方法？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

这与此帖子相关。

我想我有问题与 H2 意味着它不能正常关闭。

我怀疑这，因为我看到 myDB.lock.db 当我关闭tomcat并且进程不停止。

我使用Tomcat的连接池和数据库的URL是：

url =jdbc：h2：file：/ opt / myOrg / tomcat / webapps / MyApplication / db / myDatabase; SCHEMA = myschema



从文档关闭H2 ：


通常，数据库在最后一个连接是
时关闭....默认情况下，数据库在最后一个连接时关闭
已关闭。但是，如果它从未关闭，当
虚拟机正常退出时，使用关闭挂钩关闭数据库


我不明白我是否做错了。

我应该通过命令强制数据库关闭吗？这是关闭挂钩的意义吗？

我在这里做错了什么？



注意：

我在Google上找不到如何关闭 H2 （除了在最后一次连接关闭时自动关闭的语句之外）。我应该致电 SHUTDOWN 吗？这是正确的方法吗？

我已经看到投票，以关闭问题，但没有一个原因或链接的例子我正在调查



UPDATE：

Joonas Pulakka回答一些额外资讯后：



从 javacore 我使用了 kill -3 我看到了线程：


H2日志写入器MYAPPLICATIONJ9VMThread：0x08DC6F00，
j9thread_t：0x08C9B790，java / lang /线程：0xE7206CC8，状态：CW，prio = 5
3XMTHREADINFO1（本机线程标识：0xA32，原生
优先级：0x5，本机策略：UNKNOWN）3XMTHREADINFO2

（本地堆栈地址范围从：0xE5E26000到：0xE5E67000，
大小：0x41000）3XMTHREADINFO3 Java callstack：

4XESTACKTRACE在java / lang / Object.wait（本地方法）

4XESTACKTRACE在
java / lang / Object.wait（Object.java:196（编译代码））4XESTACKTRACE
at org / h2 / store / WriterThread.run（WriterThread.java:102）

4XESTACKTRACE在java / lang / Thread.run（Thread.java:736）



3XMTHREADINFOpool-8-thread-1J9VMThread：0x087C0200，
j9thread_t：0x0840566C，java / lang / Thread：0xE79BFC80，state：P，prio = 5

3XMTHREADINFO1（本机线程ID：0xE1A，本机
优先级：0x5，本机策略：UNKNOWN）3XMTHREADINFO2

（本机堆栈地址范围：0xE5F69000至：0xE5FAA000，
大小：0x41000）3XMTHREADINFO3 Java调用堆栈：

sun / misc / Unsafe.park（本地方法）下的4XESTACKTRACE


处的4XESTACKTRACE 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（编译
代码））4XESTACKTRACE在
java / util / concurrent / ThreadPoolExecutor $ Worker.run（ThreadPoolExecutor.java:918）
4XESTACKTRACE在java / lang / Thread.run java：736）



3XMTHREADINFOH2文件锁看门狗
opt / myOrg / tomcat / webapps / MyApplication / db / myDatabase.lock.db
J9VMThread：0x08DC6900，j9thread_t：0x08C9BA24，ja

va / lang / Thread：0xE71E9018，状态：CW，prio = 9 3XMTHREADINFO1

（本机线程ID：0xA30， 0x9，本机策略：UNKNOWN）

3XMTHREADINFO2（本机堆栈地址范围：0xE5DBA000，
到：0xE5DFB000，大小：0x41000）3XMTHREADINFO3 Java
callstack：4XESTACKTRACE at
java / lang / Thread.sleep（Native方法）4XESTACKTRACE

在java / lang / Thread.sleep（Thread.java:851（编译代码））

4XESTACKTRACE at
org / h2 / store / FileLock.run（FileLock.java:490）4XESTACKTRACE

在java / lang / Thread.run（Thread.java:736）



3XMTHREADINFOFileWatchdogJ9VMThread：0x087C0800，
j9thread_t：0x08C9B4FC，java / lang / Thread：0xE715D878，状态：CW，prio = 5

3XMTHREADINFO1（本机线程ID：0xA2C ，原生
优先级：0x5，本机策略：UNKNOWN）3XMTHREADINFO2

（本地堆栈地址范围从：0xE5E67000到：0xE5EA8000，
大小：0x41000）3XMTHREADINFO3 Java callstack：

4XESTACKTRACE在java / lang / Thread.sleep（本地方法）
4XESTACKTRACE在
java / lang / Thread.sleep（Thread.java:851（编译代码））4XESTACKTRACE
at org / apache / log4j / helpers / FileWatchdog.run（FileWatchdog.java:104）



解决方案

文档说，当虚拟机正常退出时，H2 db连接被关闭。这就是它做的。默认情况下，关闭挂钩已经存在，你不必做任何事情。



如果你有 .lock.db

，你就可以关闭资源， code>关闭后剩余的文件，则虚拟机未正常退出。您写了该过程不会停止。你必须找到原因，因为这也可以防止H2关闭挂钩执行。



对于大数据库，关闭可能需要一些时间。请参阅调试器（例如VisualVM）在调用（Tomcat）关闭后，哪些线程保持活动状态。

有更多可能性：文件权限设置为H2可以创建锁定文件，但无法 删除它们。如果操作系统阻止H2删除其锁定文件，则没有很多H2可以做到。


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)

解决方案

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.

这篇关于什么是关闭H2的正确方法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
Java开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆