CDD Configuration Procedures : Entity-Level Configuration for Cache and Backing Store

Entity-Level Configuration for Cache and Backing Store
Using their entity resource metadata properties, you can configure individual concepts and events, both at the type and at the individual property level. Such configuration is not generally required. However, it is available for advanced object management tuning or for special situations.
See Managing Storage and Retrieval of Entity Objects in TIBCO BusinessEvents Architect’s Guide for an overview that is relevant to these settings.
Metadata Properties for Entities (Events and Concepts)
Metadata properties in an entity’s Metadata section are used to fine-tune backing store behavior. Additional meta properties that may appear are used with TIBCO BusinessEvents add-ons. Only backing-store metadata properties are documented in this section. In most cases metadata property configuration is not required.
Metadata properties exist both at the entity level, and at the property level.
Note  These properties are ignored if the backing store feature has not been configured for the application or if it is configured but disabled in the CDD editor. See Cluster Tab — Cache OM — Backing Store Settings.
For the Oracle-only (legacy) backing store, you can enter a custom type name, instead of the Oracle type name generated by the backing store scripts. This is useful for giving short or meaningful names to types.
You can enter a custom table name, instead of the name generated by the backing store scripts. This is useful for giving short or meaningful names to types. This setting is used for both the JDBC backing store and the Oracle-only (legacy) backing store. See Set Metadata Properties for Long Identifiers, as Desired for more details.
The property Agent.AgentClassName.cacheTxn.updateCache is set to false.
If set to true: When a rule action changes the value of any of this entity’s properties, then the entity instance is evicted from the cache (updates are saved in the backing store)
Use as needed to improve performance and cache memory management. For example, if an entity is not accessed frequently, it may save memory in the cache if the entity is evicted from cache after it is updated.
The processing unit has a special local cache used only for entities marked as Constant. Entities placed in this cache are only removed when they are explicitly deleted. If the processing unit finds an entity in the constant cache, it will use it without checking in the cluster.
If set to true  The entity is marked "Constant", and uses the constant cache.
If set to false  (default value) The entity does not use the constant cache.
The processing unit uses a local cache, of limited size, to improve access time to the concepts stored in the cluster cache. When a processing unit finds a concept instance in this local cache, the Check for Version setting determines whether the processing unit will use the instance directly, or instead check in the cluster cache for more recent version.
If set to true  (default value) The processing unit will check in the cluster cache for a more recent version. If a more recent version exists, it will be used, and will replace the one found in the local cache
If set to false  The processing unit will use the instance found locally.
If a limited cache is used at the global level, you can set this property to false so that this entities instances are all stored in the cache.
If a limited cache is not used at the global level, you can set this property to true so that this entity’s instances are stored in the cache only to a certain limit, and additional objects are stored in the backing store.
There is no entity-level setting for the size of a limited cache. The size is set using this cluster-wide property: