Как заставить поток Java закрыть подключение к локальной базе данных потока

Оберните свой Runnable новым Runnable с конструкцией

try {
  wrappedRunnable.run();
} finally {
  doMandatoryStuff();
}

и позвольте THAT выполняться вместо этого.

Вы даже можете превратить его в метод, например:

  Runnable closingRunnable(Runnable wrappedRunnable) {
    return new Runnable() {
      @Override
      public void run() {
        try {
          wrappedRunnable.run();
        } finally {
          doMandatoryStuff();
        }
      }
    };
  }

, и вызвать этот метод передает исполняемый файл, который вы ищете.

Вы также можете рассмотреть возможность использования вместо него Executor. Облегчает управление исполняемыми и вызываемыми объектами.

Если вы все же используете ExecutorService, вы можете использовать его как Executor.submit (closedRunnable (normalRunnable))

Если вы знаете, что будете отключены весь ваш ExecutorService и хотите, чтобы соединения закрывались в этот момент, вы можете установить фабрику потоков, которая также закрывает «после того, как все задачи выполнены и завершение работы вызвано исполнителем», например:

Обычная практика JDBC заключается в том, что вы закрываете Соединение (и Заявление и ResultSet ) в одном и том же блоке метода. как вы его приобрели.

В коде:

Connection connection = null;

try {
    connection = getConnectionSomehow();
    // Do stuff.
} finally {
    if (connection != null) {
        try {
            connection.close();
        } catch (SQLException e) {
            ignoreOrLogItButDontThrowIt(e);
        }
    }
}

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

Если вы изначально намеревались улучшить производительность подключения, вам нужно найти соединение объединение . Вы можете использовать, например, API C3P0 . Или, если это веб-приложение, используйте встроенные средства пула соединений сервера приложений в виде DataSource .

Я действительно не понимаю, почему вы не используете традиционный пул соединений. Но я предполагаю, что у вас есть свои причины.

Сколько у вас свободы? Поскольку некоторые структуры DI поддерживают жизненные циклы объектов и переменные с областью видимости потоков (все они хорошо проксируются). Не могли бы вы использовать один из них? Я думаю, что Spring сделает все это из коробки, в то время как Guice потребуется сторонняя библиотека для обработки жизненных циклов и областей потоков.

Затем, какой у вас контроль над созданием переменной ThreadLocal или созданием потоки? Я предполагаю, что у вас есть полный контроль над ThreadLocal, но вы не ограничены никаким при создании потоков?

Могли бы вы использовать Aspect-ориентированное программирование для отслеживания новых Runnable или потоков, расширяющих метод run () для включения очистки? Вам также потребуется расширить ThreadLocal, чтобы он мог зарегистрироваться.

Вам нужно было открыть соединение один раз, поэтому вам также придется обрабатывать закрытие в том же месте. В зависимости от вашей среды потоки могут использоваться повторно, и вы не можете ожидать, что поток будет собран сборщиком мусора перед завершением работы приложения.

Переопределите метод get () в ThreaedLocal, чтобы он устанавливал свойство List для подкласса. Это свойство можно легко запросить, чтобы определить, был ли вызван метод get () для конкретного потока. Затем вы можете получить доступ к ThreadLocal, чтобы очистить его в этом случае.

Обновлено в ответ на комментарий

Я думаю, что в общем случае для этого нет хорошего решения, кроме классического: код, который получает ресурс, должен отвечать за его закрытие.

В конкретном случае, если вы вызываете потоки до такой степени, вы можете передать соединение своим методам в начале потока либо с помощью метода, который принимает настраиваемый параметр, либо с помощью некоторой формы внедрения зависимостей. Затем, поскольку у вас есть код, который обеспечивает соединение, у вас есть код, который его удаляет.

Здесь может работать внедрение зависимостей на основе аннотаций, поскольку код, который не требует соединения, не получит его и, следовательно, не будет ' его не нужно закрывать, но похоже, что ваш проект слишком далеко от проекта, чтобы модифицировать что-то подобное.