Пулы соединений с источником данных для каждого пользователя (через домен безопасности) в jboss-6.0.0.Final vs wildfly-10.1.0.Final - PullRequest
0 голосов
/ 27 мая 2018

Вернемся к Jboss-6.0.0. Наконец, у нас было следующее определение источника данных / пула:

<datasources>
  <xa-datasource>
   <jndi-name>pgsql</jndi-name>
   <track-connection-by-tx>true</track-connection-by-tx> 
   <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
   <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
   <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
   <xa-datasource-property name="DatabaseName">somedb</xa-datasource-property>
   <security-domain>postgresqluser</security-domain> 
   <min-pool-size>0</min-pool-size>
   <max-pool-size>5</max-pool-size>
 </xa-datasource>
</datasources>

Определение для postgresqluser домена безопасности было:

<application-policy name="postgresqluser">
 <authentication>
  <login-module code="org.jboss.resource.security.CallerIdentityLoginModule" flag="required">
    <module-option name = "managedConnectionFactoryName">jboss.jca:service=XATxCM,name=pgsql</module-option>
  </login-module>
 </authentication>
</application-policy>

Таким образом, это дало нам один пул на пользователя с максимальным размером 5 (5 - самое большее, что приложение требует + 1).Если один из пользователей злоупотребил системой и попытался получить более 5 соединений (например, быстро нажав F5), остальные пользователи не пострадали, поскольку все, что он / она мог сделать, это заблокировать ожидание большего количества соединений.

Теперьмы перенесли вышеуказанную конфигурацию в wildfly-10.1.0. Наконец, следующее:

<xa-datasource jndi-name="java:/pgsql" pool-name="smaDS" enabled="true" use-ccm="true" mcp="org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool" statistics-enabled="true">
 <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
 <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
 <xa-datasource-property name="DatabaseName">somedb</xa-datasource-property>
 <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
 <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
 <driver>postgresql-9.4.1212.jar</driver>
 <xa-pool>
  <min-pool-size>0</min-pool-size>
  <initial-pool-size>0</initial-pool-size>
  <max-pool-size>5</max-pool-size>
  <allow-multiple-users>true</allow-multiple-users>
  <wrap-xa-resource>true</wrap-xa-resource>
 </xa-pool>
 <security>
   <security-domain>postgresqluser</security-domain>
 </security>
</xa-datasource>

<security-domain name="postgresqluser">
 <authentication>
  <login-module code="org.picketbox.datasource.security.CallerIdentityLoginModule" flag="required">
   <module-option name="password-stacking" value="useFirstPass"/>
  </login-module>
 </authentication>
</security-domain>

Поведение, которое мы наблюдали, отличается, кажется, что wildfly дает первому пользователю его 5 соединений, которые могут работатьдо тех пор, пока другой пользователь не войдет в систему.Когда второй пользователь входит в систему, он, похоже, дает ему 5 соединений (просматривая активность и журналы postgresql), но, похоже, он не может выполнять какую-либо работу со всеми 10 соединениями одновременно, а затем второйпользователь блокируется или некоторые попытки подключения первого пользователя также блокируются.Указав max-pool-size = 10 в wildfly, похоже, удастся успешно обработать первых двух пользователей.Я знаю (просматривая журналы), что пул по умолчанию в wildfly использует стратегию: org.jboss.jca.core.connectionmanager.pool.strategy.PoolBySubjectAndCri.Так что я думаю, что теперь в семантике подпулов wildfly было изменено значение разделения одного и того же пула вместо нескольких экземпляров пула, как это было в случае с jboss-6.0.0.Final.

Это мое пониманиеправильный?И если да, что означает, что максимальный размер пула применяется ко всему пулу, то есть ли способ ограничить количество подключений на пользователя?(Я знаю, что мы могли бы ограничить пользователей на уровне базы данных, но мы хотели бы иметь возможность реплицировать старое поведение, прежде чем мы перейдем к новым изменениям).

...