Using a database load utility with the runtime environment
By default, the runtime environment writes contact and response history data from session data into staging tables. On a very active production system, however, the amount of memory required to cache all the data before runtime can write it to the staging tables may be prohibitive. You can configure runtime to use a database load utility to improve performance.
When you enable a database load utility, instead of holding all contact and response history in memory before writing to the staging tables, runtime writes the data to a staging file. You define the location of the directory containing the staging files with the externalLoaderStagingDirectory property. This directory contains several subdirectories. The first subdirectory is the runtime instance directory, which contains the contactHist and respHist directories. The contactHist and respHist directories contain uniquely named subdirectories in the format of audienceLevelName.uniqueID.currentState, which contain the staging files.
Current State
You can define the runtime instance directory by defining the interact.runtime.instance.name JVM property in the application server startup script. For example, you could add -Dinteract.runtime.instance.name=instance2 to your web application server startup script. If not set, the default name is DefaultInteractRuntimeInstance.
The samples directory contains sample files to assist you with writing your own database load utility control files.
To enable a database load utility with runtime environment