WAS v8.5 > WebSphere applications > EJB applications

Access intent policies for EJB 2.x entity beans

An access intent policy is a named set of properties or access intents that govern data access for EJB persistence. We can assign policies to an entity bean and to individual methods on an entity bean's home, remote, or local interfaces during assembly. We can set access intents only within EJB v2.x-compliant and later modules for entity beans with CMP v2.x.

WAS v8.5 supplies a number of access intent policies that specify permutations of read intent and concurrency control; the pessimistic and update policy can be qualified further. The selected policy determines the appropriate isolation level and locking strategy used by the run time environment.

transition: Access intent policies are specifically designed to supplement the use of isolation level and access intent method-level modifiers found in the extended deployment descriptor for EJB version 1.1 enterprise beans. We cannot specify isolation level and read-only modifiers for EJB version 2.x and later enterprise beans.

Access intent policies configured on an entity basis define the default access intent for that entity. The default access intent controls the entity unless we specify a different access intent policy based on either method-level configuration or application profiling.

Deprecated feature: Method level access intents were deprecated in v6.x..

We can use application profiling or method level access intent policies to control access intent more precisely. Method-level access intent policies are named and defined at the module level. A module can have one or many policies. Policies are assigned, and apply, to individual methods of the declared interfaces of entity beans and their associated home interfaces. A method-based policy is acted upon by the combination of the EJB container and persistence manager when the method causes the entity to load.

For entity beans that are backed by tables with nullable columns, use an optimistic policy with caution. The top down default mapping excludes nullable fields. We can override this when doing a meet-in-the-middle mapping. The fields used in overqualified updates are specified in the ejb-rdb mapping. If nullable columns are selected as overqualified columns, partial update should also be selected.

When using DB2 for z/OS v8, nullable OCC columns create no problems. This is true for JDBC and SQLJ deploy options, and partial and full update.

An entity that is configured with a read-only policy that causes a bean to be activated can cause problems if updates are attempted within the same transaction. Those changes are not committed, and the process displays an exception because data integrity might be compromised.

Subtopics

• Concurrency control
  Concurrency control is the management of contention for data resources. A concurrency control scheme is considered pessimistic when it locks a given resource early in the data access transaction and does not release it until the transaction is closed. A concurrency control scheme is considered optimistic when locks are acquired and released over a short period of time at the end of a transaction.
• Read ahead scheme hints
  read ahead schemes enable applications to minimize the number of database round trips by retrieving a working set of container-managed persistence beans for the transaction within one query. read ahead involves activating the requested CMP beans and caching the data for their related beans, which ensures that data is present for the beans that an application most likely needs next. A read ahead hint is a representation of the related beans to read. The hint is associated with the findByPrimaryKey method for the requested bean type, which must be an EJB 2.x-compliant CMP entity bean.
• Database deadlocks caused by lock upgrades
  To avoid database deadlocks caused by lock upgrades, we can change the access intent policy for entity beans from the default of wsPessimisticUpdate-WeakestLockAtLoad to wsPessimisticUpdate, or we can use an optimistic locking approach.
• Access intent assembly settings
  Access intent policies contain data-access settings for use by the persistence manager. Default access intent policies are configured on the entity bean.
• Concurrency control
  Concurrency control is the management of contention for data resources. A concurrency control scheme is considered pessimistic when it locks a given resource early in the data access transaction and does not release it until the transaction is closed. A concurrency control scheme is considered optimistic when locks are acquired and released over a short period of time at the end of a transaction.
• Read ahead scheme hints
  read ahead schemes enable applications to minimize the number of database round trips by retrieving a working set of container-managed persistence beans for the transaction within one query. read ahead involves activating the requested CMP beans and caching the data for their related beans, which ensures that data is present for the beans that an application most likely needs next. A read ahead hint is a representation of the related beans to read. The hint is associated with the findByPrimaryKey method for the requested bean type, which must be an EJB 2.x-compliant CMP entity bean.
• Database deadlocks caused by lock upgrades
  To avoid database deadlocks caused by lock upgrades, we can change the access intent policy for entity beans from the default of wsPessimisticUpdate-WeakestLockAtLoad to wsPessimisticUpdate, or we can use an optimistic locking approach.
• Access intent assembly settings
  Access intent policies contain data-access settings for use by the persistence manager. Default access intent policies are configured on the entity bean.

Related

Use access intent policies for EJB 2.x entity beans

Reference:

Access intent -- isolation levels and update locks
Access intent exceptions

+

Search Tips   |   Advanced Search