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 differs from a normal EJB finder or ejbSelect method, which also takes an EJB query but returns a collection of EJB objects (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 deals with creating, populating, and updating copy helper objects can be replaced with a DataGraph and a DMS.Important: The EJB Data Mediator Service has support for EJB2.x container managed persistence (CMP) entity beans only.

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 by 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 as it avoids EJB activation. However, if business logic or EJB container function is required by the application, then writing back through EJB is the preferred approach. When writing back through EJB, one can specify a user defined MediatorAdapter to allow 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 EJB 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 update to insure that the current value is still equal to the old value of the field in the DataObject.

 

What happens at run time?

An EJB mediator request is a compound EJB query, which consists of an ordered list of more or less 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 which is used to create references between DataObjects. More details about how the DataGraph schema is derived from the query can be found in DataGraph schema.

 

See also

EJB data mediator service programming considerations
EJB data mediator service data retrieval
EJB data mediator service data update
EJB mediator query syntax
DataGraph schema

 

Related Tasks

Using the Enterprise JavaBeans data mediator service for data access

 

---