WAS v8.5 > Develop applications > Develop data access resources > Develop data access applications > Develop data access applications > Data access with Service DataObjects, API versions 1.0 and 2.01

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.

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 we use, an optimistic concurrency control algorithm is used. Fields designated as consistency fields are read during the update to ensure 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


Related


Use the EJB data mediator service for data access


+

Search Tips   |   Advanced Search