EJB data mediator service programming considerations
When you begin writing your applications to take advantage of the Enterprise JavaBeans (EJB) data mediator service (DMS) provided in WebSphere Application v6 , you should consider the following items.
EJB programming model
Only a subset of the Enterprise JavaBeans programming model is supported by the EJB data mediator service.
- When using EJB collection parameters to retrieve data from EJB instances, or when using applyChanges to update EJB instances:
- The EJB DMS uses local interfaces for enterprise beans. Getter and setter calls for container managed persistence (CMP) fields must be promoted to the local interface, as well as any EJB methods used in query expressions.
- For the mediator to create an EJB, there must be a create method using the primary key class as the only argument method defined on the EJB home. If no such method exists, supply an adapter that handles the create operation. Also, the EJBLocalHome interface defined for the EJB must include (in addition to the create method) the following method
remove (java.lang.Object) findByPrimaryKey(<primaryKeyClass>)
- When invoking the applyChanges method directly to the database, the following occur:
- you bypass container update. You should force a refresh as soon as possible by transaction termination and using appropriate container cache options.
- you bypass EJB container managed relationship (CMR) maintenance. You must rely on database RI to maintain those relationships not retrieved into the DataGraph.
- CMP fields must be the allowed types. See EJB mediator query syntax for a list of those types.
- CMP fields of user defined types that use EJB converters/composer are not supported.
The following table shows limitations in the EJB programming model that are not supported by the EJB DMS.
retrieve direct from db retrieve from EJB Container update direct to db update through EJB Many:Many ejb relationship No No No No EJB persistence inheritance No No No No EJB RDB mapping multi table No Yes No Yes EJB cmp field with converter Yes Yes No Yes
Transactional
- All mediator calls (including create) must be done within a transaction scope – either a user transaction or a container transaction.
Access Intent
- The mediator is designed to be used in disconnected caching scenarios where the DataGraph is the disconnected cache. It is assumed that you defined an optimistic update access intent for your application.
- When applyChanges writes directly to the database, the structured query language (SQL) update statements executed contain a predicate that compares optimistic predicate fields values to the old values of the fields. If the comparison returns false and the update fails, an exception occurs.
- When applyChanges is done through the EJB container, the current values of the enterprise beans are compared with the old values of the optimistic predicates fields. If the values are unequal an exception occurs.
- If optimistic predicate fields are defined in the EJB-RDB mapping, then retrieve at least one of these fields. The field should be updated either by the caller or a database trigger – the mediator does not automatically increment or set the field.
- The access intent used by the mediator when retrieving directly from the database is the default access intent defined for the EJB named in the first query statement.
- When retrieving or updating data through the EJB container, the access intent in effect on the EJB is used.
Best Practices
- It is allowable to call getGraph on one mediator instance, update the returned DataGraph, and then call applyChanges on a different mediator instance. However, while they do not need the same mediator instance, they do need the same query shape. The query shape is the number and order of query statements, the fields and relationships specified in the SELECT and FROM clauses, and so on.
- Avoid repeated calls to createMediator if possible. Use parameterized queries and use getGraph to pass in different parameter values.