Shared-Read MBOs

Understand how to effectively use shared read MBOs.

	"Shared-read MBO" refers to MBOs that have caches that are populated by a shared read operation. See Populating the Cache Via a Shared Read Operation.
	All MBOs sharing the common read also share the same partition key—in other words, they are always loaded and refreshed together. See Updating Shared Read MBOs.
	Use shared read whenever possible to increase load efficiency.
	To implement transactional writer, use client parameters for child objects with create and update operations on root MBOs.
	Use multilevel insert for create operations if the EIS does not support an interface where child objects can be sent as client parameters.
	For operations, use the "Invalidate the cache" cache policy to force a refresh if the application requires a consistent object graph at the expense of performance.
	Use multiple partitions, if possible, to alleviate the cost of "Invalidate the cache," as only the affected partition needs to be refreshed.
	Always enable "Apply results to the cache" for a create operation to maintain surrogate key to (just returned) business key association.
	Use the "Apply results to the cache" cache policy for operations that are applicable only to the MBO instance on which the operation is executed. In case of an object graph, child MBOs are not updated.

Populating the Cache Via a Shared Read Operation

Shared read is an optimization that loads multiple MBOs with a single read operation. The more MBOs that share the common read, the better the performance. All the MBOs that share a common read operation also share the same partition key—the implication is that all MBOs within a partition refresh and load as a unit.

Updating Shared Read MBOs

There is no shared write or composite write operation to transactionally update shared read MBOs in an object hierarchy. However, a transactional update or create operation is still possible if the EIS provides an operation that takes dependent objects as client parameters. The application passes the children as client parameters prior to invocation. However, even if the result object hierarchy is returned, only the root object can be applied to the CDB. The CDB is inconsistent with the EIS until refreshed.

If the shared read MBOs are in a composite relationship and each one provides create and update operations, the results of all the operation replays can be applied to the CDB.

Note: A create operation uses multilevel insert support to update child attributes that require the parent’s primary key. JDBC EISs support this type of interaction and may even be able to enroll in two-phase commit for a transactional update.

Addressing Inconsistency

Since it is not always possible to apply results to the CDB for all shared read MBOs in an object hierarchy, the developer must decide whether the temporary inconsistency is an issue for the user. Regardless of whether the CDB needs to be invalidated to force a refresh, the create operation’s cache policy should always enable "Apply result to cache" to allow the CDB to associate the returned business key with the surrogate key from the device. This allows the CDB to avoid deleting the new object on the device in preparation for a new one from the EIS.

If the business requirement is such that the application must immediately have a consistent object graph, select the "Invalidate the cache" option for the operation’s cache policy to force an immediate refresh. To alleviate the impact of a refresh, use multiple partitions if possible. Instead of invalidating an entire MBO cache, only the partition involved is affected. This assumes that the CDB can detect the target partition based on the partition key of the returned results.