+

Search Tips   |   Advanced Search

Access intent service

Access intent is an application server runtime service that enables precise management of 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, we apply a policy to methods within the scope of an EJB module so that the policy becomes the default access intent for all requests upon those methods.


Access intent design considerations

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 provides hints on how WAS 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 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, we 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.

For further information on Java Persistence API (JPA) Access intent, see the topic on JPA Access intent.


Related:

  • Concurrency control
  • Access intent policies for EJB 2.x entity beans
  • Use access intent policies for EJB 2.x entity beans
  • Task overview: Application profiling
  • Use WSJPA access intent
  • Access intent -- isolation levels and update locks
  • AccessIntent interface