Управление соединением с SQL Server в Tomcat 6 - PullRequest
0 голосов
/ 08 января 2009

У нас возникли проблемы с веб-приложением Java, работающим в Tomcat 6, которое использует JDBC для подключения к базе данных SQL Server.

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

В настоящее время мы не используем пулы соединений и используем стандартный мост драйвера JDBC / ODBC / ADO для подключения к SQL Server.

Должны ли мы рассмотреть возможность использования пула соединений для устранения проблемы?

Кроме того, мы должны изменить наш драйвер на что-то вроде jTDS?

Ответы [ 3 ]

1 голос
/ 10 января 2009

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

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

Можете ли вы сказать нам:

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

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

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

1 голос
/ 11 января 2009

Это правильное поведение, если вы не закрываете соединения 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 закрывают не все, потому что вы «забыли» закрыть все ресурсы, которые вы выделили сами.

1 голос
/ 09 января 2009

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

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

...