Delayed cleanup of deleted portal pages


Overview

Portal resources, such as pages, components or portlet instances are kept persistent in the portal database. When an administrator deletes a page, all its derived pages and dependent resources and content are deleted with it. The actual deletion can take considerable time, depending on the size of the portal and the number of resources affected by the deletion. Therefore, if the deletion takes place immediately after the user completes the deletion task, this might impact portal performance for users. On the other hand, if the deletion is delayed and scheduled for an off peak time, it will not affect portal response time and thereby user experience.

The delayed deletion of pages is performed by a cleanup service.


Configure immediate or delayed deletion of portal pages

You can configure the deletion cleanup to happen either immediately when you delete the page or later:

You can change between the immediate and delayed deletion of portal pages by configuring the property value scheduler.cleanup.enabled in the Data Store Service.
scheduler.cleanup.enabled = (true)

Determines whether deletion of portal pages is performed later by the scheduled cleanup service, or immediately after the user completes the deletion task. This affects the deletion of portal pages and all their dependent resources, such as components and portlet instances.

Set this property to true if you want the deletion of pages to be delayed and performed by the scheduled cleanup service. Defaults to true, if the portal installation is based on a version of IBM WebSphere Application Server that includes the Scheduler service.

By its default schedule configuration, the cleanup service runs weekly, on Saturdays at 8 pm.


Configure delayed deletion schedule using xmlaccess.sh

You can use the xmlaccess.sh to define a daily, weekly, or monthly schedule or to to run individual cleanup tasks at arbitrary intervals.

To run cleanup tasks at arbitrary intervals:

  1. Edit...

      WP_PROFILE/PortalServer/doc/xml-samples/Task.xml

    .and uncomment and edit the entry that corresponds to the scheduled time you want to set.

    By default, the Task.xml file is set to run the scheduler immediately one time.

  2. Save changes.

  3. Import the modified Task.xml file using XmlAccess.

In order for customized schedule to be observed by the portal, enable the scheduler.cleanup.enabled property by setting it to true in the DataStoreService. For more details about this property refer to the section about Configuring immediate or delayed deletion of portal pages above.

If you delete a page with an object ID and then use xmlaccess.sh to re-create the same page with the same object ID, you might receive an error message indicating the operation was canceled because it would have caused a duplicate key value.

When you run the cleanup task, xmlaccess.sh only schedules the task to be run in WAS and returns. This does not necessarily mean that WAS runs the task immediately. To determine when a task started and ended, check the portal log SystemOut.log for the EJPDE0002I and EJPDE0003I messages. These messages confirm that the cleanup task has successfully completed. After you have confirmed this, you can run the XML script for re-creating a page with the same object ID as it had before the deletion.


Parent

Configure portal behavior


Related tasks


Set service configuration properties
XML configuration reference
Sample XML configuration files
Portal configuration services
Automated tasks for composite applications


Work with xmlaccess.sh


+

Search Tips   |   Advanced Search