Object management refers to various ways that BusinessEvents can manage the ontology object instances created by BusinessEvents.Use of the Cache manager enables rich functionality and is generally chosen for enterprise applications. In Memory object management can also play a useful secondary role in testing, and as an event router.
• Object Persistence Enables objects to be available for reuse, either in memory caches or in databases. Objects can also be recalled into the Rete network, thus extending the possible functionality of your system.
• Data Recovery Ability to survive failures without loss of data.
• Object Partitioning The ability to partition the objects among multiple JVMs. and to handle notifications of object additions, deletions, and changes to all the agents, enabling them to remain synchronized
• Object Clustering The ability to maintain multiple copies of each object in different nodes (JVMs) such that if one node fails, another node can take over (backup-count).
• Message Acknowledgment See Message Acknowledgment for information on the way each object management option handles message acknowledgment.Using cache clustering technology, object data is kept in memory caches, with redundant storage of each object for reliability and high availability. Cache data is shared across all the engines participating in the cluster.
Processing Unit A processing unit deploys as a BusinessEvents engine. One engine runs in one JVM.Agent Each processing unit contains one or more agents of different types. The main types are inference agents, which perform the inferencing work, and cache agents, which manage the objects.Agent Class An agent class is a configured agent. Configuration specifies, for example, what channels, startup rule functions, and rules the agent will use at runtime. You can deploy multiple instances of the same agent class, and you can deploy instances of different agent classes, depending on the work the application is designed to do.Data recovery after total system failure is available if you implement a persistent backing store. Recovery from failure of individual processing units (JVMs) is available with Cache OM without a backing store.Object management features provide fine-grained controls for managing the memory footprint of the cache, if you use a backing store.Fault tolerance is provided at the inference agent level. Agents belonging to the same agent class can act in a traditional fault tolerant manner, where standby agents take over for failed active agents. Fault tolerance can also be provided implicitly, because all active agents in the same class share the workload. There may be no need to keep any agents as standbys. It depends on your needs.Cache-based object management is generally the best choice for CEP systems. It offers richer functionality, and is the method that receives most focus in these chapters.
Cache-Related Features Cache-based object management enables additional features, such as features for querying the cache (additional querying features are available with TIBCO BusinessEvents Event Stream Processing add-on software), and concurrency features. Rules can also take advantage of the availability of persisted data. Load balancing of messages from a queue is also available.Cache OM offers finer-grained object management options, at the object level. See Chapter 7, Distributed Cache OM.For implementation details, see TIBCO BusinessEvents Administration.In Memory object management does not persist object instances. They are maintained in local JVM memory only. Objects are managed by standard JVM features. This is the only section on In Memory manger, because if its simplicity.In Memory OM does not provide data recovery in case of system failure. The working memory on each system is not synchronized. Object state is not maintained. At startup after a failure, object state is initialized to the application’s starting state.The In Memory option is a good choice for development and testing environments. In production environments, the In Memory option is best used for stateless operations and transient objects. An independently deployed In Memory application can act as an event router, directing events to agents in a cache cluster for processing.
For Fault Tolerance If you require fault tolerance with an in memory only system, then configure for Cache OM, but use the Memory Only mode for all objects. (In Memory OM itself does not support fault tolerance.) Because data is not persisted, it is lost during failover and failback. However, the engine process continues.Another advantage of this approach is that the in memory processing units can participate in the larger cluster, instead of being a separately deployed application.
• Do not confuse Berkeley DB object management with cache plus backing store object management. Both use a database, but are otherwise quite different.Object data is periodically written to a data store on disk. Each agent has its own data store. This option enables recovery of objects from the persisted state, but does not support built-in fault tolerance mechanisms. Custom means can be used to provide fault tolerance.The following table illustrates which features are supported for each object management option.
Data Recovery Fault Tolerance No (Use Cache with Memory Only objects) Yes (snapshot) Yes (at agent level)You can use In Memory object management in early phases of development. In later phases, you can implement Cache OM and take advantage of features it makes possible.You can also migrate a production system from Persistence to Cache. See TIBCO BusinessEvents Installation, Chapter 6, Migrating Persistence Data to Backing Store.
Perform tests after changing object management method As with any change in configuration, be sure to perform thorough testing before going into production.
Copyright © TIBCO Software Inc. All Rights Reserved.