Управление подключением к SQL Server в Tomcat 6

Это правильное поведение, если вы не закрываете соединения JDBC.

Вы должны вызвать метод close() каждого ресурса JDBC, когда закончите использовать его и другие ресурсы JDBC, полученные с его помощью.

Это касается Connection, Statement/PreparedStatement/CallableStatement, ResultSet и т. д.

Если вы этого не сделаете, для начала вы накопите потенциально огромные и, вероятно, очень ограниченные ресурсы на сервере SQL.

В конце концов, соединения не будут предоставлены, запросы на выполнение и возврат результатов завершатся с ошибкой или зависнут.

Вы также можете заметить, что ваши операторы INSERT/UPDATE/DELETE зависают, если вы не можете выполнить commit() или rollback() при завершении каждой транзакции, если вы не установили для свойства autoCommit значение true.

Что я видел, так это то, что если вы применяете упомянутую выше строгость к своему клиентскому коду JDBC, то JDBC и ваш SQL-сервер будут работать на удивление плавно. Если писать хрень, то и все будет вести себя как хрень.

Многие люди пишут вызовы JDBC, ожидая, что «что-то» еще освободит каждую вещь, вызвав close(), потому что это скучно, и приложение и сервер не сразу выходят из строя, когда они пропускают это.

Это правда, но эти программисты написали свои программы, чтобы проигрывать «99 бутылок пива на стене» на своих серверах.

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

Таким образом, самый быстрый способ решить эти типы проблем с SQL — это не обвинять SQL-сервер, сервер приложений, веб-контейнер, драйверы JDBC или разочаровывающее отсутствие искусственного интеллекта, встроенного в сборщик мусора Java.

Самый быстрый способ решить их — застрелить парня, который писал вызовы JDBC в вашем приложении, которые взаимодействуют с вашим SQL-сервером, с помощью дротика Nerf. Когда он говорит: «Зачем ты это сделал…?!» Просто укажите на этот пост и скажите ему, чтобы он прочитал его. (Помните, что нельзя стрелять в глаза, вещи в его руках, вещи, которые могут быть опасными/хрупкими и т. д.)

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

Зубная фея кладет деньги под подушку, Пасхальный кролик кладет яйца и конфеты под кусты, а Дед Мороз кладет подарки под елку. Но, извините, чтобы разрушить ваши иллюзии - SQL-сервер и драйвер JDBC не закрывают все, потому что вы "забыли" закрыть все, что вы выделили сами.

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

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

На самом деле трудно сказать, потому что вы предоставили так мало информации о фактическом сбое:

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

Вы можете рассказать нам:

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

Я написал много Java-кода, связанного с базой данных (практически весь мой код связан с базой данных), и использовал драйвер MS, драйвер jdt и драйвер jnetDirect.

Я уверен, что если вы предоставите нам более подробную информацию, мы сможем вам помочь.