от

Настройка источников данных и таймаутов Websphere / Oracle

Транзакции, особенно в распределенном приложении, с несколькими источниками данных — головная боль для разработчика. Здесь куча вещей, которые могут пойти не так. Среди прочего нужно позаботиться о корректной настройке источников данных и таймаутов. Немного систематизирую свой опыт о том, как настраиваются соединения для приложения, использующего несколько датасорсов и довольно серьезно загружающие базу запросы.

Поддержка распределенных транзакций

При распределенных транзакциях наши системы должны поддерживать технологию XA. Лишь один источник в распределенной транзакции может не поддерживать XA. Иначе мы увидим ошибку: Illegal attempt to enlist multiple 1PC XAResources. То есть мы должны понимать, что datasource provider вебсферы в общем случае должен быть XA, и что Oracle должен быть настроен для поддержки XA, и что наш пользователь должен иметь права на работу с XA.

Включение XA — задача DBA. Инструкцию можно посмотреть, например, тут, нам с позиции разработчика это не очень интересно. Однако нужно проверить видимость упомянутых представлений для пользователей, которых мы настраиваем в соединении. Вообще для всех XA-датасорсов в вебсфере мы можем настраивать отдельного пользователя Authentication alias for XA recovery. Именно этот пользователь должен иметь доступ к вьюхам XA. Он может и совпадать с основным пользователем схемы.

Screenshot from 2014-05-14 20:15:41

Таймауты

Для правильной работы с транзакциями нужно соблюдать простое правило зависимости таймаутов: Глобальный таймаут транзакций < Таймаута JDBC-соединения < DISTRIBUTED_LOCK_TIMEOUT < CONNECT_TIME/IDLE_TIME.

Глобальный таймаут транзакции настраивается на уровне сервера (Application servers > servername > Container service > Transaction service >Total transaction lifetime timeout (например 120 с).
timeout01

Таймаут JDBC-соединения настраивается на датасорсе. (Data sources > dataSourceName > Connection pools > Connection timeout (например, 180 с)

timeout02

Кстати, может оказаться полезным подправить и другие значения в настройках соединения (см. выше). Также можно установить ограничение на количество открываемых соединений в секунду, чтобы не перегрузить Oracle (в примере — 2 соединения за 1 секунду, это может и чрезчур консервативно).
Data sources > dataSourceName > Connection pools > Advanced connection pool properties

timeout03

И заставить датосорсы принудительно валидироваться (чтобы не использовать сбойные соединения) каким-нибудь простым запросом
Data sources > dataSourceName > WebSphere Application Server data source properties

timeout04

DISTRIBUTED_LOCK_TIMEOUT устанавливается в Оракле. Проверить его можно так
select value from v$parameter where upper(name) = 'DISTRIBUTED_LOCK_TIMEOUT';

А увеличит его опять же DBA (есть нюансы). Например, 240 с.

CONNECT_TIME/IDLE_TIME также задаются на уровне Оракла (UNLIMITED)

select * from user_resource_limits a
where a.resource_name in ('IDLE_TIME','CONNECT_TIME');

Write a Comment

Комментарии