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. Optionally, you can associate access intent policies with one or more methods.

These settings are applicable only for EJB 2.x-compliant entity beans that are packaged in EJB 2.x-compliant modules. Connection sharing between beans with bean-managed persistence and those with container-managed persistence is possible if they all use the same access intent policy.

Name

Specifies a name for a mapping between an access intent policy and one or more methods.

Description

Contains text that describes the mapping.

Methods - Name

Specifies the name of an enterprise bean method, or the asterisk character (*). The asterisk is used to denote all of the methods of an enterprise bean's remote and home interfaces.

Methods - Enterprise bean

Specifies which enterprise bean contains the methods indicated in the Name setting.

Methods - Type

Used to distinguish between a method with the same signature that is defined in both the home and remote interface. Use Unspecified if an access intent policy applies to all methods of the bean.
Data type String
Range Valid values are Home, Remote,Local, LocalHome or Unspecified

Methods - Parameters

Contains a list of fully qualified Java type names of the method parameters. This setting is used to identify a single method among multiple methods with an overloaded method name.

Applied access intent

Specifies how the container must manage data access for persistence. Configurable both as a default access intent for an entity and as part of a method-level access intent policy.
Data type String
Default wsPessimisticUpdate-WeakestLockAtLoad. With Oracle, this is the same as wsPessimisticUpdate.
Range Valid settings are wsPessimisticUpdate, wsPessimisticUpdate-NoCollision, wsPessimisticUpdate-Exclusive, wsPessimisticUpdate-WeakestLockAtLoad, wsPessimisticRead, wsOptimisticUpdate, or wsOptimisticRead. Only wsPessimisticRead and wsOptimisticRead are valid when class-level caching is enabled in the EJB container.

This product supports lazy collections. For each segment of a collection, iterating through the collection (next()) does not trigger a remote method call to retrieve the next remote reference. Two policies (wsPessimisticUpdate and wsPessimisticUpdate-Exclusive) are extremely lazy; the collection increment size is set to 1 to avoid overlocking the application. The other policies have a collection increment size of 25.

[Fix Pack 5.0.2 and later]If an entity is not configured with an access intent policy, the run-time environment typically uses wsPessimisticUpdate-WeakestLockAtLoad by default. If, however, the Lifetime in cache property is set on the bean, the default value of Applied access intent is wsOptimisticRead; updates are not permitted.

Additional information about valid settings follows:

Profile name Concurrency control Access type Transaction isolation
wsPessimisticRead (Note 1) pessimistic read For Oracle, read committed. Otherwise, repeatable read
wsPessimisticUpdate (Note 2) pessimistic update For Oracle, read committed. Otherwise, repeatable read
wsPessimisticUpdate- Exclusive (Note 3) pessimistic update serializable
wsPessimisticUpdate- NoCollision (Note 4) pessimistic update read committed
wsPessimisticUpdate- WeakestLockAtLoad (Note 5) pessimistic update Repeatable read
wsOptimisticRead optimistic read read committed
wsOptimisticUpdate (Note 6) optimistic update read committed

Notes:

  1. Read locks are held for the duration of the transaction.

  2. The generated SELECT FOR UPDATE query grabs locks at the beginning of the transaction.

  3. SELECT FOR UPDATE is generated; locks are held for the duration of the transaction.

  4. [Fix Pack 5.0.2 and later]A plain SELECT query is generated. No locks are held, but updates are permitted. Use cautiously. This intent enables execution without concurrency control.

  5. [Fix Pack 5.0.2 and later]Where supported by the backend, the generated SELECT query does not include FOR UPDATE; locks are escalated by the persistent store at storage time if updates were made. Otherwise, the same as wsPessimisticUpdate.

  6. Generated overqualified-update query forces failure if CMP column values have changed since the beginning of the transaction.

    [Fix Pack 5.0.2 and later]Be sure to review the rules for forming overqualified-update query predicates. Certain column types (for example, BLOB) are ineligible for inclusion in the overqualified-update query predicate and might affect your design.