WAS v8.5 > Reference > Developer best practicesEJB 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.
The update can be applied directly to the data source or through EJB instances.
When applying changes through EJB instances an optional adapter class can be specified on the applyChanges method. Each changed data object is first passed to the adapter applyChange method. The adapter can process the change itself and return true, or have the EJB Mediator process the change by returning false.
The adapter can be used to customize the optimistic concurrency (OCC) logic, or process changes to read only DataGraph attributes, or process changes that require business logic.
There are two forms of the applyChanges method. The first, applyChanges( DataObject) takes the updated DataGraph and runs structured query language (SQL) insert, update, and delete statements directly against the database, bypassing the EJB container. The second form, applyChanges( DataObject, MediatorAdapter ) processes updates using EJB instances and accessors. A null value for the MediatorAdapter is supported.
When to use an adapter with applyChanges
- Use when there are create methods other than create(PrimaryKey)
- Use when business methods must be called instead of container-managed persistence setter methods
- Use when special optimistic caching logic is needed
How the adapter works
Three passes are made over the DataGraph log, passing changed DataObject to the adapter:
- New DataObjects are passed. The adapter can create the object and set the CMP fields. Container-managed relationships (CMR) that reference enterprise beans not yet created are deferred until pass 2.
- New and updated DataObjects are passed. CMRs deferred from pass 1 can be set at this time.
- Deleted DataObjects are passed.
Related
Develop data access applications