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

Если у вас чувствительный характер, отведите взгляд сейчас.

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

public class Estragon {
  public static class Vladimir {
    Vladimir() { System.out.println("Open"); }
    public void close() { System.out.println("Close");}
  }

  private static ThreadLocal<Vladimir> HOLDER = new ThreadLocal<Vladimir>() {
    @Override protected Vladimir initialValue() {
      return createResource();
    }
  };

  private static Vladimir createResource() {
    final Vladimir resource = new Vladimir();
    final Thread godot = Thread.currentThread();
    new Thread() {
      @Override public void run() {
        try {
          godot.join();
        } catch (InterruptedException e) {
          // thread dying; ignore
        } finally {
          resource.close();
        }
      }
    }.start();
    return resource;
  }

  public static Vladimir getResource() {
    return HOLDER.get();
  }
}

Улучшение обработки ошибок и т. д. остается в качестве упражнения для разработчика.

Вы также можете посмотреть на отслеживание потоков/ресурсов в ConcurrentHashMap с опросом другого потока isAlive. Но это решение — последнее средство для отчаявшихся: объекты, вероятно, будут проверяться слишком часто или слишком редко.

Я не могу думать ни о чем другом, что не связано с инструментами. АОП может работать.

Пул соединений был бы моим предпочтительным вариантом.

Оберните свой 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. Значительно упрощает управление Runable и Callables.

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

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

  ExecutorService autoClosingThreadPool(int numThreads) {
    ThreadPoolExecutor threadPool = new ThreadPoolExecutor(numThreads, numThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>()); // same as Executors.newFixedThreadPool
    threadPool.setThreadFactory(new ThreadFactory() {
      @Override
      public Thread newThread(Runnable r) {
        return new Thread(closingRunnable(r)); // closes it when executor is shutdown
      }
    });
    return threadPool;
  }

С точки зрения того, может ли doMandatoryStuff знать, было ли соединение когда-либо открыто или нет ранее, одна вещь, которая приходит на ум, это иметь второй ThreadLocal, который просто отслеживает, было ли оно открыто или нет (например: когда соединение открыто, получить затем установите для AtomicInteger значение 2, во время очистки проверьте, остается ли оно по умолчанию, скажем, 1...)

Обычная практика JDBC заключается в том, что вы закрываете Connection (и Statement и 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, но вы не ограничены в создании потоков?

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

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

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

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

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

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

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

То, что мы сделали, было

@Override
public void run() {
  try {
    // ...
  } finally {
    resource.close();
  }
}

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

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

Например, если вы создаете Executor, расширяя ThreadPoolExecutor, вы можете переопределить методы afterExecution() и terminated() для выполнения этого. Первый для потока, завершающегося ненормально, а второй - для нормального.