Использовать расширения 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 в стратегии параллелизма, определенные в WebSphere Файле расширения EJB. Автоматизированные действия по устранению неполадок:

Эксклюзивный

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

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

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

ReadOnly

Для стратегии ReadOnly WebLogic для соответствующего боба будут установлены следующие параметры WebSphere Application Server Bean Cache боба:

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

Database

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

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

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

Optimistic

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