You can use application profiling to identify particular units of work to the WebSphere Application Server runtime environment. The run time can tailor its support to the exact requirements of that unit of work.
Access intent is currently the only runtime component that makes use of the application profiling functionality. For example, you can configure one transaction to load an entity bean with strong update locks and configure another transaction to load the same entity bean without locks.
For a Version 6.x client to interact with applications run under the Application Profiling 5.x Compatibility Mode, you must set the appprofileCompatibility system property to true in the client process. You can do this by specifying the -CCDappprofileCompatibility=true option when invoking the launchClient command.
For example, an application has two EJB modules: EJBModule1 and EJBModule2.
The EJBModule1 has an application profile named AppProfile1. This AppProfile1 is registered by a task named task1. This task1 becomes a known-to-application task and is honored when associated with a unit of work within this application. With the presence of any known-to-application task, method level access intent configurations are ignored and only bean level access intent configurations are applied.
The EJBModule2 contains no application profile configuration data. All entity beans are not configured with bean level access intent explicitly, but some methods have method level access intent configurations. If an entity bean in the EJBModule2 is loaded in a unit of work that is associated with task1, the bean-level access intent configuration is applied and method level access intent configuration is ignored. Because the bean level access intent is not set explicitly, the default bean level access intent, which is wsPessimisticUpdate-WeakestLockAtLoad, is applied.