| Immediately update the cache |
- (With Entity Read) Create and Update operations support
shared data and updates an object graph within the cache.
- (Entity Read and Operation Merge) If non-Unwired Platform
applications update the EIS, those changes are not reflected
in the cache using this cache policy and the MBO developer
instead should use another refresh mechanism to propagate
those changes to the cache; for example a cache group that
uses either an On demand, Scheduled, or DCN policy that
eventually brings the cache into consistency with the
EIS.
- (Entity Read and
Operation Merge) Supports only one root MBO for a given MBO
graph.
|
| Legacy "Apply results to the cache" |
Modifies the cache based on the returned result
set of the called MBO operation:
- By default, Create and Update operations use this
policy, which can be modified.
- Delete operations use this policy, which is always set
and cannot be modified.
- The MBO must be bound to a data source that has one or
more primary-key attributes set.
- All columns contain all key attributes.
Validation for this cache policy for Web service and SAP MBOs
includes: - A warning message if you model a Create operation that
does not have a primary key attribute.
- A warning message if you model a Create operation if the
output record does not contain the primary-key columns.
For database MBOs: - Unwired WorkSpace must execute a database MBO operation
to retrieve the output records, which can affect the
business data on the server to which the MBO is bound if
it is an Update, Delete, or Insert operation.
-
For JDBC data sources, Unwired WorkSpace
does not validate whether an operation with this
operation cache policy returns primary key fields as
part of the output record. If the MBO developer uses
this policy option, you must know whether the definition
of the operation can return the primary key column or
not.
|
| Invalidate the cache |
- The entire cache table is invalidated only if the
partitions affected by the operation cannot be
determined from the MBO attributes. If the affected
partitions can be determined, only the affected
partitions are invalidated.
- For shared data, this policy decouples the client Update
operation from the cache refresh. There is a potential
granularity mismatch if the Update operation is at a
primary key level and the cache refresh is at a
partition level; this may result in the refresh of more
data than was actually modified.
- An "On Demand" cache group policy with a zero coherence
window has the same outcome as this policy. If there are
other non-Unwired Platform applications updating EIS
data, the partition refresh pulls those data changes
into the cache.
- Do not use this policy for an operation when the MBO is
in a DCN (data change notification) cache group, since
the policy has no effect.
- To achieve optimum performance when using
cache invalidating operations, propagate
result-affecting load arguments into the MBO attributes,
which are defined in the tab.
- A partition key identifies the cache partitions affected
by the operation. Partition key definition guidelines
require that:
- An input parameter must be mapped to a
synchronization key or to an attribute of another
MBO to be considered a partition key.
- Input parameters that are mapped only to
personalization keys are excluded as partition
keys, since personalization keys are available
only within a client context and not suitable for
this cache policy. To use personalization keys as
partition keys, you must map the personalization
keys to a synchronization parameter.
- A synchronization key must be mapped to an MBO
attribute.
- If an MBO belongs to a cache group that uses a
DCN policy, the operations of that MBO do not
support an "Invalidate the cache" policy.
|