Use WebSphere extensions to define concurrency strategy

The concurrency strategy for WebLogic specifies how the container should manage concurrent access to an entity type enterprise bean. This rule detects the presence of the <concurrency-strategy> element in the weblogic-ejb-jar.xml file.

There are four WebLogic concurrency strategies that must be migrated to WebSphere traditional:

• Exclusive causes WebLogic Server to place an exclusive lock on entity Enterprise JavaBeans(TM) (EJB) instances when the bean is associated with a transaction. Other requests for the EJB instance are blocked until the transaction completes.
  
  
• ReadOnly concurrency strategy is used for read-only entity beans. It loads an instance from the database, then makes copies available for each transaction so requests can proceed in parallel. A related element called read-timeout-seconds specifies the seconds between ejbLoad() calls. A value of zero specifies the read-only bean is not to be reloaded from the database.
  
  
• Database concurrency strategy causes WebLogic to delegate locking requests for an entity bean to the underlying data store. WebLogic allocates a separate entity bean instance to each transaction and enables locking and caching to be handled by the database. This is the default option.
  
  
• Optimistic concurrency strategy holds no locks in the EJB container or database during a transaction. The EJB container verifies that none of the data updated by a transaction has changed before committing the transaction. If any updated data changed, the EJB container reverts to the previous the transaction.
  
  

In the source scanner, the quick fix provided for this rule migrates your concurrency strategies defined in weblogic-ejb-jar.xml to concurrency strategies defined in the WebSphere EJB extension file. You can use the quick fix preview option to see the changes before you apply the quick fix.

Source scanner quick fix actions:

Exclusive

For the Exclusive WebLogic strategy, the following WebSphere(R) Application Server bean cache options are set for the corresponding bean:

• Activate at is set to ONCE.
• Load at is set to ACTIVATION.

These parameters avoid calls to ejbLoad function and serialize access to the bean instance. This option increases memory utilization by maintaining persistent state in the cache but can provide better response time if the bean instance is not generally accessed concurrently. This is caching Option A in the EJB specification.

ReadOnly

For the ReadOnly WebLogic strategy, the following WebSphere Application Server Bean Cache options are set for the corresponding bean:

• Activate at is set to ONCE.
• Load at is set to INTERVAL.
• Reload interval is set to the appropriate number of seconds between reloads. This value is taken from the WebLogic <read-timeout-seconds> element which is also in seconds. If <read-timeout-seconds> is set to 0 in WebLogic, then ejbLoad is called only when the instance is first brought into the cache. In WebSphere Application Server, a Reload integer interval value of 0 also causes the container to never reload the bean.

Database

For the Database WebLogic strategy, the following WebSphere Application Server bean cache options are set for the corresponding bean:

• Activate at is set to TRANSACTION.
• Load at is set to TRANSACTION.

This is the default for the WebSphere Application Server bean cache. Since it is the default, it does not have to be explicitly set it for each of the beans that use the database concurrency strategy; however, the quick fix does explicitly set it. This strategy is also referred to as caching Option C in the EJB specification.

Optimistic

For the Optimistic WebLogic strategy, optimistic locking is used in WebSphere. The access intent is set in the WebSphere extension file to wsOptimisticUpdate. Also, when the CMP map is created, the OptimisticPredicate property is set to TRUE for all fields that are defined in the weblogic-cmp-rdbms-jar.xml file as <verify-columns>. These columns are checked for updates before committing the changes to the database. If a change is detected, the transaction is rolled back.