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 removes operator data from memory if an operator is not active.
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).
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.
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).
- Setting passivation and requestor time-outs
Passivation allows a requestor, service, or clipboard page to be saved into the Pega Platform database and reactivated later, helping to free up JVM memory and making more memory available to other requestors.
- 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.