Enterprise JavaBeans Data Mediator Service

The EJB Data Mediator Service (DMS) is the Service Data Objects (SDO) Java interface that, given a request in the form of EJB queries, returns data as a DataGraph containing DataObjects of various types.

This is different from a typical EJB finder or ejbSelect method, which also takes an EJB query but returns a collection of EJB objects that are all of the same type or a collection of container managed persistence (CMP) values.

The EJB DMS enables you to specify an EJB query that returns a data graph (the DataGraph) of data objects (DataObjects). The query can be expressed as a compound EJB query contained in a string array of EJB query statements. One advantage of using a DataGraph is that much of the code written in an EJB facade session bean that creates, populates, and updates copy helper objects can be replaced with a DataGraph and a DMS.

Important: The EJB DMS has support for EJB2.x container managed persistence (CMP) entity beans only. It does not support EJB 3.x modules.

We can obtain a DataGraph using the getGraph call, either from EJB instances cached in the container, or the query request can be compiled into SQL and executed directly against the data source.

Updated DataObjects can be written back to the data store using the applyChanges method in one of two ways. The updates can be translated into SQL and applied directly to the data store or can be written back through EJB accessor methods. Writing back directly to the data store can improve performance because it avoids EJB activation. However, if business logic or EJB container function is required by the application, writing back through EJB is the preferred approach. When writing back through EJB, we can specify a user-defined MediatorAdapter method to ensure customized handling of changed DataObjects. This customization can include application-specific optimistic concurrency control, invoking business methods on the EJB to perform updates, update of computed values in the DataObject, and calling application-specific create methods on EJBHome.

Update processing is not dependent on how the DataGraph was originally retrieved. In other words, it is possible to retrieve a DataGraph directly from the data source, but have the deferred updates applied through the enterprise bean or the other way around.

Regardless of which update approach you use, an optimistic concurrency control algorithm is used. Fields designated as consistency fields are read during the update to ensure that the current value is equal to the old value DataObject field.

Runtime processing

An EJB mediator request is a compound EJB query, which consists of an ordered list of regular EJB queries. Each query in the compound query defines an SDO. The SELECT clause of the query specifies the CMP fields or expressions to return in the DataObject. The WHERE clause specifies the filtering conditions. The first query in the list is considered to be the ROOT node in the DataGraph. The FROM clause of a query, other than the first, specifies an EJB relationship used to create references between DataObjects. More details about how the DataGraph schema is derived from the query can be found in the topic DataGraph schema.

Subtopics

• EJB data mediator service programming considerations
  When you begin writing the applications to take advantage of the EJB data mediator service (DMS) provided in the product, consider the following items.

• EJB data mediator service data retrieval
  An EJB mediator request is a compound EJB query. We can obtain a DataGraph using the getGraph call.

• EJB data mediator service data update
  An EJB mediator request is a compound EJB query. We can write an updated DataGraph back to the data source using the applyChanges method.

• EJB mediator query syntax
  When you begin writing the applications to take advantage of the EJB data mediator service (DMS) provided in the product, consider the following items.

• DataGraph schema
  

Related tasks

Use the EJB data mediator service for data access