Adding bean-level access intent for entity beans 2.x

Access intent for EJB 2.x entities is the replacement in the EJB 2.x specification for the EJB 1.x access intents and EJB 1.x isolation levels.
There are two general methods for adding access intent to enterprise beans 2.x:
  • Bean-level access intent (Default): this default method for handling access intent based on the bean level should be used in most cases.
  • Method-level access intent: this advanced method for handling access intent based on methods should only be used in advanced situations.

To add default access intent (bean level) to an enterprise bean 2.x:

  1. Switch to the J2EE perspective.
  2. In the Project Explorer view, click EJB Projects, find your project, then click ejbModule > META-INF > ejb-jar.xml. The EJB Deployment Descriptor window opens.
  3. On the Access page of the editor, select one or more beans, under the Default Access Intent for Entities 2.x (Bean Level) section, click Add. The Add Access Intent wizard opens.
  4. In the Access intent name field, select an access intent type from the list.
  5. Optional: Type a description for the new access intent.
  6. To set the persistence, select Persistence Option. You have three persistence options:

    • If you select Verify Read Only Data , select on option for read-read consistency checking from the list:
      • NONE No read-read checking is done.
      • AT_TRAN_BEGIN Read-read checking is done during ejbLoad, if the data is from cache, check the database to ensure that the data of the bean has not changed since the last load (with proper locking based on access intent's concurrency control attribute).
      • AT_TRAN_END Read-read checking is done at the end of transaction, if the bean is not changed and did not load by the current transaction, check the database to ensure that the data of the bean has not changed from last load (with proper locking based on access intent's concurrency control attribute). If the data has changed, fail the transaction.
      For examples on read-read consistency checking, see Examples: read-read consistency checking.

    • If you select Partial Operation, select on option for partial operation from the list:
      • NONE This is the default setting, where all the persistent attributes of the CMP bean to the database are stored to the database, even though a subset of the persistent attributes fields might have been changed.
      • UPDATE_ONLY Limit updates to the database to only persistent attributes of the CMP bean that have been modified.
      For more details on partial operation, see Partial operation for container managed persistence.

    • If you select Deferred Operation, select on option for deferred operation from the list:
      • NONE Nothing is deferred.
      • CREATE_ONLY Only ejbCreate commands are deferred until the next ejbStore occurs to create row in database.
      • ALL All ejbCreate, ejbStore, and ejbRemove commands are deferred until a flush is needed, which is either before a finder method or before transaction completion.
      For more information on deferred operation, see Deferred create for container managed persistence.

  7. The batch operation uses the JDBC batch command to insert, update, or delete rows in the database backend that this particular enterprise bean is connected to. For more information on the batch operation, see Batch commands for container managed persistence . To select the batch operation:
    1. In the Deferred Operation, select ALL . (You must select All to use the batch option.)
    2. Check the Batch box.
  8. Click Finish.
The access intent is added. To remove the access intent, select it and click the Remove button.

Feedback