TIBCO BusinessEvents Cache Fundamentals

Object management (OM) refers to various ways that TIBCO BusinessEvents can manage the objects created by the actions of an inference agent’s rules and rule functions. You define the OM options in the project’s CDD file. The objects being managed of the types defined in the ontology, that is, concepts, scorecards and events. In the Project Design Tutorial, you used In Memory OM.

With In Memory OM, when an engine shuts down, all its data is lost. This option is useful for a project where objects are not created or do not have to be persisted, for example, one project that routes incoming events to other TIBCO BusinessEvents projects for handling.

 When you use Cache OM, objects are persisted redundantly in memory caches. Each TIBCO BusinessEvents engine (JVM) participates as a node in the cache cluster. The cache manager manages the objects across the JVMs.

 TIBCO BusinessEvents uses a pre-configured distributed cache scheme.

In a distributed cache, the cached object data is partitioned between cluster nodes (TIBCO BusinessEvents engines). Each object is stored redundantly in two or more nodes, for reliability and high availability: if one engine fails, the objects are re-partitioned across the remaining engines so that the configured number of backups is maintained.

 With a distributed cache, one or more engines can fail without loss of data (depending on the number of backups of each object). However if all engines fail, the data is lost. For this reason it is common to write the objects to a database, known as the backing store.

TIBCO BusinessEvents provides tools to create the backing store for a project. When you use a backing store you can also use a limited cache and populate it as needed from the backing store, balancing performance and memory requirements as needed. (To learn how to set up the backing store, see Backing Store Tutorial.)

 Cache agents store and serve the cache data for the cluster. They participate in distribution, partitioning and storage of the objects in the cluster.

An engine (processing unit) that runs a cache agent cannot run any other agents of any type. (For testing you can configure an inference agent to act also as a cache agent, but this is not recommended for production systems.)

Besides cache agents and inference agents, the Query agents can also join the cluster.

The inference agents can use objects in the cache as well as those they create from data coming in through channels (or create internally using rules and rule functions). Cached concept objects are shared by all agents in the cluster, scorecards are kept local to an agent, and events are clustered between the agents.

Each object type can use a different mode: Cache Only, Store Only, and Memory Only.

Cache-only is the default and that is the behavior described in the rest of this tutorial.

At the end of each RTC, that is, each "run to completion" cycle, data is flushed from the Rete network to the cache. In this way the Rete network does not become clogged with irrelevant data. (This behavior occurs when the entities are configured to use cache-only mode, which is the default and is strongly recommended.)

Before each RTC, you must load the relevant data into the Rete network from the cache. If you do not then cached data that is needed by the rules triggered by incoming events is not present. For example, a request to create a new account arrives through a channel.

It is important to check that no matching account already exists in the cache before you create the new account. To do so, you use an event preprocessor rule function to load any matching accounts into the Rete network. Then in the RTC rules can check for existing accounts and avoid creating duplicates.

Use this mode for entity types whose data is transient and does not need to be persisted.

By default one backup of each cache object is maintained. Backups are maintained in different cache agents.

You can increase the number of backups by changing the Number of Backup Copies setting in the Object Management area of the CDD.

Multiple inference agents can run concurrently, sharing the same ontology and same cache cluster.

Another way to achieve concurrency is to use the multi-threaded Rete feature, which also requires cache OM. With agent or RTC concurrency, you must use locking: in both cases multiple RTCs are being processed at the same time, and data must be protected as in any concurrent system.

The tutorial does not demonstrate concurrency features. See TIBCO BusinessEvents Architect’s Guide for more details.