Chapter 16 Configuring Persistence Object Management : BusinessEvents Archive Resource Object Management Tab—Persistence Settings Reference

BusinessEvents Archive Resource Object Management Tab—Persistence Settings Reference
Other tabs of the BusinessEvents Archive Resource are documented in Chapter 26, Deploytime Configuration.
 
One of In Memory, Persistence, or Cache. Default is In Memory. See Chapter 14, Understanding Object Management and Fault Tolerance for information on each option. When you select Persistence, persistence configuration settings appear. Configure the settings as explained in this section.
Checkpoint Interval
A checkpoint is the point in time at which working memory data is written to disk. The checkpoint interval is the time, in seconds, between writes to disk.
Note: No changes can occur in the rule session during a checkpoint.
If you want to use only the Outstanding Database Operations setting, set Checkpoint Interval to zero (0).
Schedule a checkpoint if outstanding DB ops greater than
Database operations include object creations, updates, and deletions. An outstanding database operation is one that is held in working memory only (it has not yet been written to disk). When the number of outstanding database operations exceeds the Max Outstanding Database Operations value, a checkpoint occurs.
When the persistence layer performs cleanup, the least recently used (LRU) properties are moved to the persistence store, to reduce the number of properties in memory to the specified number.
Delete Retracted Objects from Database
When objects are retracted (deleted) from the working memory, they are marked with a retraction flag. You can delete them from the persistence database, or you can leave them in the database (flagged with the retraction flag).
It is recommended that you delete retracted objects to avoid accumulating large numbers of retracted objects in the database. However, you may want to keep retracted objects in the database for reporting or data mining purposes.
Do Not Recover on Restart
Check this field to disable recovery features. In this case, the persistence database is used as virtual memory only.
When recovery features are disabled, performance improves because the processing required to support the recovery features is not done.
When you check the Do Not Recover on Restart checkbox, data is lost in the event of a system failure.
Database Environment Directory
Persistence files for the rule session are stored under the Database Environment directory on the target machine when the project is deployed. Enter the file path from the deployed engine to the directory.
By default (if you do not specify a directory), persistence files are located under the BusinessEvents engine’s working directory, in directories named db/session_name. (See Default Location of Log Files and Other Files and Directories for details.)
Tip: If you can’t determine the location of a deployed application’s persistence files, search for their filenames. The persistence file directory contains one file called je.lck and one or more files called 00000000.jdb, 00000001.jdb, and so on.
Checkpoint Interval and Outstanding Database Operations
You can schedule checkpoints based on the Checkpoint Interval only, or on the Max Outstanding Database Operations only, or on both settings. It is recommended that you use both settings. When you do so, data is written to disk as follows:
When the Checkpoint Interval passes (even if fewer than the Max Outstanding Database Operations have occurred).
When the Max Outstanding Database Operations value is exceeded within the Checkpoint Interval. BusinessEvents then resets the Checkpoint Interval timer.
For example, assume the checkpoint interval is thirty seconds and the number of outstanding database operations is defined as five. Thirty seconds passes with only three outstanding database operations, so BusinessEvents performs a checkpoint. Then ten seconds passes and six database operations occur, so again, BusinessEvents performs a checkpoint. BusinessEvents also resets the checkpoint interval timer.
Caches Used for Persistence-Based Object Management
If your system has sufficient memory, you can improve performance by increasing the number of concept properties kept in memory for this rule session. When determining how many concept properties to keep in memory, consider the size of the properties — some may be quite large. Also consider your other requirements for memory.
Two caches are used with the Persistence option: a concept property cache and an event cache. The Property Cache size controls how many concept properties are kept in JVM memory. You define similar settings for the event cache in the be-engine.tra file.
Additional memory management settings also are available in the be-engine.tra file. They enable you to control the percentage of JVM memory that is set aside for use by the persistence layer’s internal cache. See Engine Property File Settings for Persistence Object Management.
Defining the Database Directories for Each Rule Session (Inference Agent)
If your project has multiple rule sessions (or if you will deploy the same application multiple times on the same machine) you must ensure that each rule session has its own database environment directory. Use one of the following options to set the values at deploy time:
Create a different global variable for each BAR file, and use the appropriate variable in each BAR’s Database Environment Directory field. At deploy time, set values for the rule sessions in each instance.
Use the be.engine.om.berkeleydb.dbenv engine property (in be-engine.tra). At deploy time, directories are automatically created for each rule session under the directory you specify. Then do one of the following:
For TIBCO Administrator deployment, add the property to the Advanced tab and define the directory differently before deploying the project each time. See Customizing the List of Properties on the Advanced Tab for more details.
For command line deployment, define the property in override property files and specify the appropriate file using -p option at deploy time.