Configuring your system for passivation and activation
Passivation and activation help with system performance and high availability. Passivation allows a requestor, service, or clipboard page to be saved into storage and reactivated later, helping to free up JVM memory.
Passivation
Passivation removes operator data from memory if an operator is not active.
When a page is passivated, other pages for that requestor remain in memory, and requestor processing continues normally until that page is needed (such as for read access or for update) and is reactivated into memory. When an entire thread is inactive, the thread context is passivated (including the associated clipboard pages). If the requestor remains idle, eventually the entire requestor context is passivated.
Pega Platform uses database passivation by default, with filesystem passivation available as an alternate method.
To add a process to occur before passivation (for example, saving all call data and closing all tabs in a customer service application), use the pyPrePassivation activity. In order for this activity to be run as expected, you must implement the activity with the correct applies-to class (@baseclass).
Activation
If the operator continues working after a period of inactivity, the system retrieves their work from storage and puts it back into memory, referred to as activation.
When a requestor is activated, the pages that had previously been passivated remain in storage until they need to be activated. If a page is later re-passivated, it is updated accordingly.
To add a process to occur after activation (for example, reconnecting a user with a dropped call), use the pyPostActivation activity. In order for this activity to be run as expected, you must implement the activity with the correct applies-to class (@baseclass).
- Changing the default passivation time-out settings
Passivation time-out is required for high availability environments and is enabled by default. The length of time that pages, threads, or requestors are idle before they are passivated is defined by default. To change passivation times, add the passivation settings to the dynamic system settings and then enter the preferred values.
- Defining passivation storage
Pega Platform provides two passivation storage mechanisms: database and filesystem. The default passivation storage is database, which is most efficient and robust. You can override the default storage mechanism by setting the prconfig setting initialization/persistrequestor/storage to either database, filesystem, or custom.
- Reporting on passivated requestors
To see a list of passivated requestors on the PegaRULES database, open and run the standard list view report System-Requestor-Context.RequestorContextList.ALL.
Previous topic Understanding high availability for developer environments Next topic Changing the default passivation time-out settings