Many composites will be long running, taking minutes, hours, or days to complete. To avoid unnecessary memory usage and to provide resilience in case of machine failure these composites will be persisted to the SOA Suite repository database. This process is known as dehydration and it involves storing the current execution state of the composite in the database. Usually this state is stored and managed by the BPEL component. When an event occurs that requires the composite to take some action, such as a timer expiring or a message arriving, then the SOA Suite retrieves the composite state from the database and schedules it for execution. A composite may be dehydrated multiple times during its life.