2016-07-19 1 views
1

В настоящее время мы переносим приложения для работы на сервере Liberty (8.5.5.9). Мы обнаружили, что соединения между сервером приложений и базой данных иногда прерываются брандмауэром, поскольку они простаивают в течение длительного периода времени. Когда это произойдет, в следующем HTTP-запросе приложение получит одно из этих сломанных соединений.В пуле соединений WAS Liberty я могу проверить соединения по заимствованию?

Раньше мы использовали DBCP Apache Commons для управления пулом соединений. Один из configuration parameters in a DBCP conneciton pool - «testOnBorrow», который не позволяет приложению получить одно из этих плохих соединений.

Есть ли такой параметр конфигурации в источнике данных, управляемом Liberty?

До сих пор, мы настроили наш источник данных, как это:

<dataSource jndiName="jdbc/ora" type="javax.sql.DataSource"> 
     <properties.oracle 
      user="example" password="{xor}AbCdEfGh123=" 
      URL="jdbc:oracle:thin:@example.com:1521:mydb" 
     /> 
     <connectionManager 
      minPoolSize="3" maxPoolSize="10" maxIdleTime="10m" 
      purgePolicy="ValidateAllConnections" 
     /> 
     <jdbcDriver id="oracle-driver" libraryRef="oracle-libs"/> 
    </dataSource> 

purgePolicy в настоящее время устанавливается для проверки всех соединений, если один плохой один найден (например, ночью, когда все соединения были простаивает в течение длительного время). Но все это предотвращает последовательное передачу нескольких плохих соединений приложениям.

Одним из вариантов в connectionManager было бы установить ageTimout = "20m", чтобы автоматически удалять соединения, которые достаточно стары, чтобы уже были прерваны брандмауэром. Однако это также приведет к прекращению соединений, которые были недавно использованы (что предотвращает их нарушение).

Я пропустил что-то очевидное здесь? Спасибо!

+1

Я бы предложил использовать ageTimeout, так как много брандмауэров не заботятся о том, используется ли соединение или нет, и просто убивайте соединения, которые открыты в течение длительного времени. – Gas

ответ

2

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

согласно maxIdleTime документу:

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

Поскольку у вас есть ваш minPoolSize=3, бассейн не будет очередным обслуживание пинать, если есть только 3 плохие соединения в пуле, например, потому что содержание нить не будет не будет брать размер пула ниже минимума согласно документу. Поэтому установка minPoolSize=0 должна позволить maxIdleTime очистить все плохие соединения, как вы ожидали бы в этом сценарии.

Так вот окончательная конфигурация, что я хотел бы предложить вам:

<dataSource jndiName="jdbc/ora" type="javax.sql.DataSource"> 
    <properties.oracle user="example" password="{xor}AbCdEfGh123=" 
         URL="jdbc:oracle:thin:@example.com:1521:mydb"/> 
    <connectionManager maxPoolSize="10" maxIdleTime="18m"/> 
    <jdbcDriver id="oracle-driver" libraryRef="oracle-libs"/> 
</dataSource> 

Значение maxIdleTime предполагает, что ваш брандмауэр убивает соединения после 20 минут, и, чтобы вызвать очистку после 18 минут для того, чтобы дать поток очистки - 2-минутное окно, чтобы очистить соединения, которые скоро будут плохими.

+0

Я собираюсь попробовать сегодня, чтобы узнать, работает ли он так, как рекламируется. Спасибо за указатели. –

+0

Выглядит хорошо ... еще раз спасибо! –

 Смежные вопросы

  • Нет связанных вопросов^_^