WAS v8.5 > Develop applications > Develop EJB applications > Assemble access intents to EJB 2.x entity beansAccess intent service
Access intent is an application server runtime service that enables you to precisely manage an application's persistence.
The access intent service defines a set of declarative annotations used by the EJB container and its agents to make performance optimizations for entity bean access. These annotations are organized into sets called access intent policies.
Access intent policies contain a set of annotations considered as hints by the EJB container and its agents. Most access intent policies are hints representing high-level abstractions that can be mapped to a specific back end resource manager. It is the responsibility of the EJB persistence machinery to ensure the necessary concurrency control, connection, and cache management when carrying out the persistence details. The EJB persistence manager can use access intent hints to make better performance decisions when carrying out its assigned task. A smaller number of access intents are hints to the EJB container, influencing the management of EJB collections.
Typically, you configure bean level access intent for the applications. We can also apply access intent policies to beans within the scope of application profiles. Consequently, we can configure beans with multiple and opposing access intent policies. The application profiling documentation explains in more detail how to configure an application to apply a particular access intent policy to a bean for one request, then apply another access intent policy to the same bean for a different request.
Support for applying access intent policies at the method level is deprecated in WebSphere Application Server v6.0. In this practice of configuring access intent, you apply a policy to methods within the scope of an EJB module so the policy becomes the default access intent for all requests upon those methods.
Access intent design considerations
Best practice: Refrain from over-tuning an application. We can introduce errors by incorrectly using the access intent service. For example, misuse of the wsPessimisticUpdate-NoCollision policy can result in lost updates; inappropriately setting the collection increment value can introduce performance issues; and problem determination is more difficult when an application is configured with multiple access intent policies.best-practices
Clarity and simplicity should be your guiding principles when using the access intent service. This is even more important when applying access intent polices within the scope of application profiles.
Even though access intent policies can be configured on any method of an entity bean, some attributes of a policy can only be leveraged by the runtime environment under certain conditions. For example, concurrency and access intent are only used for CMP entity beans when the ejbLoad method is driven to open a connection and read data from a given resource; that data is cached and used to drive the proper queries during invocation of the ejbStore method. Read-ahead hints are only used during the execution of a finder for a bean. The collection increment and resource manager prefetch increment are only used on multi-object finders. Configuring policies on methods that do not use the policy is not an error. Only certain attributes of any policy are used, even when the policy is appropriately applied to a method. However, configuring policies unnecessarily throughout an application obscures the design of the application and complicates the maintenance of the application.
Access intent with BMP entity beans
Access intent's declarative functionality provides great power to you as a CMP entity bean developer. We can provide hints on how the product should manage the details of persistence without having to explicitly manage any of the persistence logic in the application. There are situations, however, in which we might need to develop BMP entity beans. Since the only meaningful difference between BMP and CMP components is who provides the persistence logic, BMP entity beans should be able to leverage access intent hints just as the product does on behalf of CMP entity beans. BMP entity beans that use the access intent service participate in application profiling; that is, the value of the access intent attributes can differ from request to request, allowing the BMP entity bean to seamlessly modify its persistence strategy.
We can apply access intent policies to BMP entity bean methods as well as CMP entity bean methods. Because access intent hints are not contractual in nature, there is no obligation for a BMP entity bean to exploit them. BMP entity beans are expected to use only those access intent attributes that are important to that particular bean.
The current access intent policy is bound into the java:comp namespace for a particular BMP entity bean. That policy is current only for the duration of the method call during which the access intent policy was retrieved. In a typical scenario, you would cache the access type during invocation of the ejbLoad method so that appropriate actions can be taken during invocation of the ejbStore method.
Access intent best practices
When applying access intent policies to EJB methods, consider the following issues.
- Start by configuring the default access intent policy for an entity. After the application is built and started, we can tune certain access paths in the application using application profiling or method-level access intent.
- Don't mix access types. Avoid using both pessimistic and optimistic policies in the same transaction. For most databases, pessimistic and optimistic policies use different isolation levels. This can result in multiple database connections, which prevents you from taking advantage of the performance benefits possible through connection sharing.
- Take care when applying the wsPessimisticUpdate-NoCollision policy. This policy does not ensure data integrity. No database locks are held, so concurrent transactions can overwrite each other's updates. Use this policy only if we can be sure that only one transaction attempts to update persistent store at any time.
For further information on JPA Access intent, see the topic on JPA Access intent.
Related concepts:
Concurrency control
Access intent policies for EJB 2.x entity beans
Related
Use access intent policies for EJB 2.x entity beans
Tasks: Application profiling
Use JPA access intent
Reference:
Access intent -- isolation levels and update locks
Related information:
AccessIntent interface