Использовать расширения WebSphere для определения стратегии параллельного доступа

Стратегия параллельного доступа в WebLogic определяет, каким образом контейнер должен управлять параллельным доступом к сущностному EJB. Это правило проверяет наличие элемента <concurrency-strategy> в файле weblogic-ejb-jar.xml.

Существует четыре стратегии параллельного доступа WebLogic, которые необходимо мигрировать в WebSphere traditional:

• Exclusive (исключительный доступ) - WebLogic Server создает исключительную блокировку экземпляров сущностного Enterprise JavaBeans(TM) (EJB), если EJB связан с транзакцией. Другие запросы к экземпляру EJB блокируются, пока транзакция не будет выполнена.
  
  
• ReadOnly (только чтение) - применяется для EJB, доступных только для чтения. Экземпляр загружается из базы данных, и для каждой транзакции создается своя копия, чтобы запросы могли обрабатываться параллельно. В связанном элементе read-timeout-seconds задается интервал между вызовами ejbLoad(). Нулевое значение указывает, что применяемый только для чтения EJB не перезагружается из базы данных.
  
  
• Database (база данных) - WebLogic делегирует запросы на блокировку сущностного EJB базовому хранилищу данных. WebLogic выделяет отдельный экземпляр сущностного EJB каждой транзакции, позволяя базе данных управлять блокировками и кэшированием. Этот вариант выбран по умолчанию.
  
  
• Optimistic (оптимистическая стратегия) - во время транзакции ни в контейнере EJB, ни в базе данных не создаются никакие блокировки. Перед фиксацией транзакции контейнер EJB проверяет, что обновленные транзакцией данные не изменялись никем другим. Если какие-либо данные изменялись, контейнер EJB восстанавливает то состояние данных, которое было до транзакции.
  
  

Быстрое исправление, предусмотренное в сканере исходного кода для этого правила, преобразует стратегии параллельного доступа, определенные в weblogic-ejb-jar.xml, в стратегии параллельного доступа, определенные в файле расширений EJB WebSphere. Используя функцию предварительного просмотра быстрого исправления, можно проверить изменения, прежде чем применять быстрое исправление.

Действия в ходе быстрого исправления сканером исходного кода:

Exclusive

В случае стратегии WebLogic Exclusive для соответствующего EJB устанавливаются следующие параметры кэширования EJB WebSphere(R) Application Server:

• В поле Активировать при устанавливается значение ONCE.
• В поле Загружать при устанавливается значение ACTIVATION.

Эти параметры позволяют избежать вызова функции ejbLoad и сериализуют доступ к экземпляру EJB. Такой вариант увеличивает расход памяти за счет поддержания постоянного состояния в кэше, однако обеспечивает достаточно хорошее время ответа в том случае, если параллельный доступ к EJB происходит нечасто. Это соответствует варианту кэширования A в спецификации EJB.

ReadOnly

В случае стратегии WebLogic ReadOnly для соответствующего EJB устанавливаются следующие параметры кэширования EJB WebSphere Application Server:

• В поле Активировать при устанавливается значение ONCE.
• В поле Загружать при устанавливается значение INTERVAL.
• В поле Интервал повторной загрузки задается необходимый интервал в секундах между операциями повторной загрузки. Это значение берется из элемента <read-timeout-seconds> WebLogic, который также содержит значение в секундах. Если <read-timeout-seconds> в WebLogic равен 0, то ejbLoad вызывается только при первом размещении экземпляра в кэше. В WebSphere Application Server нулевой интервал повторной загрузки также означает, что контейнер никогда не перезагружает EJB.

Database

В случае стратегии WebLogic Database для соответствующего EJB устанавливаются следующие параметры кэширования EJB WebSphere Application Server:

• В поле Активировать при устанавливается значение TRANSACTION.
• В поле Загружать при устанавливается значение TRANSACTION.

Этот вариант применяется по умолчанию в кэше EJB WebSphere Application Server. В связи с этим его не требуется отдельно задавать для каждого EJB, использующего стратегию параллельного доступа Database. Тем не менее, быстрое исправление явно его настраивает. Данная стратегия соответствует варианту кэширования C в спецификации EJB.

Optimistic

Вместо применяемой в WebLogic стратегии Optimistic в WebSphere применяется оптимистическая блокировка. В качестве цели доступа в файле расширения WebSphere задается значение wsOptimisticUpdate. Кроме того, при создании связи CMP задается значение TRUE в свойстве OptimisticPredicate всех полей, которые определены в файле weblogic-cmp-rdbms-jar.xml как <verify-columns>. В этих столбцах проверяется наличие обновлений перед фиксацией изменений в базе данных. При обнаружении обновлений выполняется откат транзакции.