Каков правильный способ закрыть 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 себя? Это правильный подход?
Я уже вижу голоса, чтобы закрыть вопрос, но не было причины или ссылки на пример того, что я исследую

обновление:
После Joonas Pulakka ответить на некоторые дополнительные сведения:

С javacore я получил с помощью kill -3 Я вижу темы:

"H2 Log Writer MYAPPLICATION" J9VMThread: 0x08DC6F00, j9thread_t:0x08C9B790, java/lang / поток: 0xE7206CC8, состояние: CW, prio=5 3XMTHREADINFO1 (идентификатор собственного потока: 0xA32, native приоритет: 0x5, собственная политика: неизвестно) 3XMTHREADINFO2
(собственный диапазон адресов стека от: 0xE5E26000 до: 0xE5E67000, размер: 0x41000) 3xmthreadinfo3 Java callstack:
4XESTACKTRACE на java/lang / Object.ждать(родной Метод)
4XESTACKTRACE в java/lang / Object.подождите (Object.java: 196 (скомпилированный код)) 4XESTACKTRACE в org/h2/store / WriterThread.run (WriterThread.java: 102)
4XESTACKTRACE на java/lang / Thread.run (поток.java: 736)

3xmthreadinfo "пул-8-поток-1" J9VMThread: 0x087C0200, j9thread_t:0x0840566C, java/lang / Thread:0xE79BFC80, состояние: P, prio=5
3XMTHREADINFO1 (идентификатор собственного потока: 0xE1A, native приоритет: 0x5, собственная политика: неизвестно) 3XMTHREADINFO2
(собственный диапазон адресов стека от: 0xE5F69000 до: 0xE5FAA000, размер: 0x41000) 3xmthreadinfo3 Java callstack:
4XESTACKTRACE на солнце / разное / небезопасно.парк (родной метод)
4XESTACKTRACE в java/util/concurrent/locks / LockSupport.парк(LockSupport.java: 184 (скомпилировано Код)) 4XESTACKTRACE на java/util/concurrent/locks / AbstractQueuedSynchronizer$ConditionObject.await (AbstractQueuedSynchronizer.java: 1998 (составлено Код)) 4XESTACKTRACE на java/util/concurrent / LinkedBlockingQueue.взять(LinkedBlockingQueue.java: 413 (скомпилировано Код)) 4XESTACKTRACE на java/util/concurrent / ThreadPoolExecutor.getTask (ThreadPoolExecutor.java: 958 (скомпилировано Код)) 4XESTACKTRACE на java/util/concurrent / ThreadPoolExecutor$Worker.запустить(ThreadPoolExecutor.java: 918) 4XESTACKTRACE на java/lang / Thread.run (поток.java: 736)

3xmthreadinfo " H2 файл блокировки сторожевой опт/myOrg/котяра/веб-приложения/Мое_приложение/дБ/данных mydatabase.замок.децибел" J9VMThread: 0x08DC6900, j9thread_t: 0x08C9BA24, ja
va/lang / Thread: 0xE71E9018, состояние: CW, prio=9 3XMTHREADINFO1
(идентификатор собственного потока: 0xA30, собственный приоритет: 0x9, собственная политика: неизвестно)
3XMTHREADINFO2 (собственный диапазон адресов стека от: 0xE5DBA000, кому: 0xE5DFB000, размер: 0x41000) 3xmthreadinfo3 Java стек вызовов: 4XESTACKTRACE в java/lang / Thread.sleep (собственный метод) 4XESTACKTRACE
на java/lang / Thread.сон (нить.java: 851 (скомпилированный код))
4XESTACKTRACE в org/h2/store / FileLock.run (FileLock.java: 490) 4XESTACKTRACE
на java/lang / Thread.run (поток.java: 736)

3XMTHREADINFO "FileWatchdog" J9VMThread: 0x087C0800, j9thread_t:0x08C9B4FC, java/lang / Thread:0xE715D878, состояние: CW, prio=5
3XMTHREADINFO1 (идентификатор собственного потока: 0xA2C, native приоритет: 0x5, собственная политика: неизвестно) 3XMTHREADINFO2
(собственный диапазон адресов стека от: 0xE5E67000 до: 0xE5EA8000, размер: 0x41000) 3xmthreadinfo3 Java callstack:
4XESTACKTRACE на java/lang / Thread.сон (родной метод) 4XESTACKTRACE на java/lang / Thread.сон (нить.java: 851 (скомпилированный код)) 4XESTACKTRACE в org/apache/log4j/помощники / FileWatchdog.run (FileWatchdog.java: 104)

20
database-connection h2 java jdbc tomcat

5 ответов

в документации говорится, что соединение H2 db закрывается, когда виртуальная машина выходит нормально. И это то, что он делает. Крючок выключения уже есть по умолчанию, вам ничего не нужно делать. Закрытие крюк-это отличный способ закрытия ресурсов, которые должны быть закрыты при выходе.

Если у вас .lock.db файлы, оставшиеся после завершения работы, то виртуальная машина не нормально. Ты это написал!--4-->процесс не остановить. Вы нужно найти причину этого, потому что, вероятно, это то, что также предотвращает выполнение крючка выключения H2.

при больших базах данных закрытие может занять некоторое время. См. с отладчиком (например, VisualVM), какие потоки остаются активными после завершения работы (Tomcat).

существует больше возможностей: права доступа к файлам установлены так, что H2 может создать файлы блокировки, но не может удалить них. Если ОС не позволяет H2 удалять файлы блокировки, H2 мало что может с этим поделать.

9

глядя на DbStarter.contextDestroyed()код (благодаря Allan5 ' s ответ), вот код, который будет работать:

connection.createStatement().execute("SHUTDOWN");

так Аарон Digulla ' s ответ был правильным (даже если не полностью "копировать/pastable").

более того, если вы запустили TCP-сервер H2 с помощью server = Server.createTcpServer("-tcpAllowOthers"), вы можете остановить его, просто используя server.stop().

3

Вы можете выполнить инструкцию SHUTDOWN и затем закрыть соединение.

на SHUTDOWN команда сделает H2 свободным все ресурсы, связанные с подключением немедленно. Это, например, позволит вам избавиться от встроенной базы данных H2 при повторном развертывании веб-приложения.

2

нет, крюк выключения-это просто поток, который запускается, когда JVM завершается, независимо от того, возвращается ли из main (), вызывая систему.выход (int) или создание исключения. Только авария JVM избежала бы этого. Среды Выполнения.методы addshutdownhook(нить).

1

не уверен, что это имеет отношение к вашей ситуации, но вы пытались добавить прослушиватель DBStarter?

http://www.h2database.com/html/tutorial.html, см. раздел" Использование прослушивателя сервлетов для запуска и остановки базы данных".

ссылка предлагает добавить в web следующее.XML-код:

<listener>
    <listener-class>org.h2.server.web.DbStarter</listener-class>
</listener>

см. обсуждение здесь (по общему признанию, с 2008 года, поэтому может быть устаревшим) - по-видимому, исправление относится как к встроенным, так и к не встроенным экземплярам: http://groups.google.com/group/h2-database/browse_thread/thread/eb609d58c96f4317

альтернативно, как вы используете соединения? Вы уверены, что правильно очищаете соединения?

у меня были проблемы раньше, в моем случае я использовал соединение с JPA EntityManager, и я забыл закрыть экземпляр EntityManager после использования, что привело к некоторым проблемам:

@PersistenceUnit(unitName="myEm")
private EntityManagerFactory emf;

public void doStuff() {
    EntityManager em = emf.createEntityManager();
    ...
    em.close(); // forgot this line
}
1