Java JDBC соединения и Oracle - PullRequest
       17

Java JDBC соединения и Oracle

0 голосов
/ 05 июня 2010

У меня есть сценарий, и вопрос следует

Сервер приложений имеет два пула соединений с БД. A и B

A указывает на -> DatabaseA -> имеет 128 connections

A имеет хранимые процедуры, которые обращаются к таблицам, находящимся в DatabaseB через DB link

B указывает на -> DatabaseB -> имеет 36 connections

Теперь предположим, что код Java вызывает Stored Proc в DatabaseA, используя пул соединений A. Этот сохраненный процесс получает данные по ссылке в БД от DatabaseB

Вопрос:

Исходя из этого сценария, если мы получим connection closed ошибок во внешнем интерфейсе. Можно ли сказать, что, хотя java вызывает SP (в DatabaseA) из пула A (128), но поскольку SP доставляет данные из DatabaseB, он имеет меньшее количество соединений (36).

По сути, я хочу знать, когда данные передаются по ссылке в БД, как это ... Отнимает ли это 36 подключений, назначенных точке пула B, к базе данныхB?

Точное исключение Я получаю точное исключение: --- Cause: java.sql.SQLException: Closed Connection

Некоторые трассировки стека:

Вызывается: java.sql.SQLException: Закрытое соединение на com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback (GeneralStatement.java:185) в com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryForList (GeneralStatement.java:123) в com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForList (SqlMapExecutorDelegate.java:614) в com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForList (SqlMapExecutorDelegate.java:588) в com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForList (SqlMapSessionImpl.java:118) в org.springframework.orm.ibatis.SqlMapClientTemplate $ 3.doInSqlMapClient (SqlMapClientTemplate.java:268) в org.springframework.orm.ibatis.SqlMapClientTemplate.execute (SqlMapClientTemplate.java:193) в org.springframework.orm.ibatis.SqlMapClientTemplate.executeWithListResult (SqlMapClientTemplate.java:219) в org.springframework.orm.ibatis.SqlMapClientTemplate.queryForList (SqlMapClientTemplate.java:266)

Кроме того, я использую iBatis ... поэтому у меня нет try..catch..finally блоков

Ответы [ 3 ]

2 голосов
/ 05 июня 2010

Хранимая процедура выполняется в базе данных; когда он устанавливает соединение с другой базой данных, он устанавливает прямое соединение и не проходит через пул сервера приложений. Фактически, он может установить соединение с любой базой данных, связанной с A, независимо от того, существует ли пул соединений с этой базой данных, поддерживаемый сервером приложений.

0 голосов
/ 05 июня 2010

"По сути, я хочу знать, когда данные передаются по ссылке в БД, как это ... Отнимает ли это 36 подключений, назначенных точке пула B, к базе данныхB?"

Нет. Сервер базы данных устанавливает отдельное соединение с другим сервером базы данных независимо от пула соединений.

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

0 голосов
/ 05 июня 2010

Это исключение указывает на утечку ресурса, т. Е. Код JDBC неправильно закрывает соединения в блоке finally (чтобы гарантировать его закрытие даже в случае исключения), или соединение используется несколькими потоками. Если два потока совместно используют одно и то же соединение из пула, и один поток закрывает его, то это исключение произойдет, когда другой поток использует соединение.

Код JDBC должен быть написан так, чтобы соединения (и операторы, и наборы результатов) были получены и закрыты (в обратном порядке) в одном и том же блоке метода. Э.Г.

Connection connection = null;
// ...
try {
     connection = database.getConnection();
     // ...
} finally {
     // ...
     if (connection != null) try { connection.close(); } catch (SQLException logOrIgnore) {}
}

Другой возможной причиной является то, что пул слишком долго удерживает соединения в режиме ожидания и не проверяет / проверяет их перед освобождением. Это настраивается в приличном пуле соединений. Обратитесь к его документации.

...