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.

About this task

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:

Procedure

  1. Switch to the Java™ EE perspective.
  2. In the Enterprise Explorer view, expand your EJB 2.x project and double-click the Deployment Descriptor node.
  3. On the Access page of the EJB deployment descriptor editor, select one or more beans, under the Default Access Intent for Entities 2.x (Bean Level) section, click Add.
  4. In the Access intent name field, select an access intent type from the list. For details on these access intent types, see the table in the Access intent assembly settings topic available from the WebSphere® Application Server Information Center.
  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 an option for checking the consistency of "read-read" operations (comparing of data in bean with data in the data source). Options include:
      • 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.
      .

    • 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.

    • 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.

  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. 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.

Results

The access intent is added. To remove the access intent, select it and click the Remove button.

Feedback