When you begin writing your applications to take advantage of the Enterprise
JavaBeans (EJB) data mediator service (DMS) provided in WebSphere Application
Version 6.0 , 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:
- 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
you must 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.