When you begin writing your applications to take advantage
of the Enterprise JavaBeans (EJB) data mediator service (DMS) provided
in the product, consider the following items.
EJB programming model
Only a subset of the
EJB 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:
- 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.
Table 1. EJB
programming model limitations with EJB DMS. 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 |
EJB persistence inheritance |
No |
No |
No |
No |
EJB cmp field with converter |
No |
Yes |
No |
Yes |
Transactional
- All mediator calls, including create, must be done within a transaction
scope either a user transaction or a container transaction.
The various mediator calls including, create, getGraph, and applyChanges,
do not have to be called within the same transaction. In fact, most
often the calls are done in separate transactions.
Best practices
- You can 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.