Package org.exoplatform.addons.documents.cleanup.service

Class CleanupExecutionService

java.lang.Object
org.exoplatform.addons.documents.cleanup.service.CleanupExecutionService
@Service public class CleanupExecutionService extends Object
Asynchronous batched purge of a LOCKED campaign, under a JCR system session. The correctness guarantee is the per-item revalidation at delete time: a node that disappeared, got exempted, was excluded or no longer matches the criteria is spared, whatever the dry-run said.

  • Constructor Details

    • CleanupExecutionService

      public CleanupExecutionService()

  • Method Details

    • shutdown

      @PreDestroy public void shutdown()

    • startExecution

      public CleanupCampaign startExecution(long campaignId) throws org.exoplatform.commons.exception.ObjectNotFoundException
      Switches a campaign to EXECUTING and launches the asynchronous purge. TWO states may enter it, and the retry is the reason there are two: LOCKED (the normal run, once the grace deadline elapsed) and COMPLETED (the retry of CleanupCampaignService#retryCampaign, which requeues the retryable failures and then reuses this very method verbatim).
      Parameters:
      campaignId - campaign identifier
      Returns:
      the updated campaign
      Throws:
      org.exoplatform.commons.exception.ObjectNotFoundException - when the campaign doesn't exist

    • resumeExecution

      public void resumeExecution(long campaignId)
      Resumes after a restart the purge of a campaign left EXECUTING: the worker is naturally resumable, it iterates the remaining CANDIDATE items. No-op when this campaign's worker is already running.
      Parameters:
      campaignId - campaign identifier

    • executeCampaignTransactional

      public void executeCampaignTransactional(long campaignId)

    • executeCampaign

      protected void executeCampaign(long campaignId)
      Execution worker, running as system (no conversation state needed). Package visible for tests.

    • restartTransaction

      protected void restartTransaction()
      Commits the current batch and opens a fresh transaction. Extracted as a single static call so the worker tests — which drive the worker body directly, with no PortalContainer booted — can neutralize it.

      The NO-ARG form is the correct one here: ContainerTransactionalAspect sets the current container to the PortalContainer before its RequestLifeCycle.begin and restores it afterwards, so ExoContainerContext.getCurrentContainer() inside the worker IS the right container. And restartTransaction ends then begins the SAME number of nested lifecycles, so the aspect's own end() in its finally block stays balanced.