When maintaining a large database it is important to have a reliable Purge tool that can be scheduled to run without crashing.
The below propsal aims at improving todays functionality to make purge a little more reliable
Basic understanding of Purge
Preference "Chunk Size" is set to specify how many objects should be processed at the same time (here set to 20 000, see below)
Query to collect a large number of objects specified/created
Purge executed or scheduled to run
The query returns a set of found objects matching the criteria
The above objects are sent to the “Purge loop” where they are processed 20 000 objects at a time (in “Purge sub loops”)
For each purge operand, a number of checks are made to ensure it can be removed
When all(?) objects have been checked, the EPMDOCUMENT table in the (Oracle) database is locked and deletion starts. Here is seems some more checks and rollbacks are done which may result in a lock that can be active for more than 1h preventing users from moving objects for example
If some unhandled exception is thrown during Purge, the entire Purge loop is terminated. If some handled exception is thrown only the Purge sub loop seems to terminate(?)
When all chunks are processed or some unhandled error is thrown Purge is ready with a status matching the outcome of the processing
Purge is running in a sub loop, processing a chunk
Some user, or Purge itself is modifying a workspace
Below unhandled error is thrown and terminates the entire Purge loop
SEVERE ERROR: Unhandled exception occurred during processing. Cannot continue Purge operation.
A persistence error occurred. System message follows:
Nested exception is: wt.util.WTException: Baseline "wt.epm.workspaces.EPMCheckpoint:1276739228" is currently being modified by another user. The operation cannot be completed.
No objects could be purged. The Purge operation "100614_Purge_NA-20" has failed.
When above error is thrown, only the Purge sub loop should terminate (i.e. the chunk), not the entire Purge execution.
If possible, this type of error should not have to impact Purge at all. A simple re-do should be able to handle this