Package org.exoplatform.caldav.job

Class CaldavSyncSweepJob

java.lang.Object
org.exoplatform.caldav.job.CaldavSyncSweepJob
@Component public class CaldavSyncSweepJob extends Object
Keeps connected CalDAV accounts fresh without waiting for their owner.

Until this ran, synchronisation only ever happened because someone opened their agenda — and it happened while they waited, since the page talks to a server outside the platform before it can list anything. The throttle kept that off every render, at the price of making the first open after a quiet stretch the slow one; and an account whose events changed elsewhere stayed stale until its owner happened to look.

The job holds no logic of its own: it reads its two bounds from properties and hands the work to the service, as a scheduled task should.

Setting the cron to - turns the sweep off entirely, which is the right answer for an instance with a handful of CalDAV users: their own page loads already synchronise them.

  • Constructor Details

    • CaldavSyncSweepJob

      public CaldavSyncSweepJob()

  • Method Details

    • sweep

      @Scheduled(cron="${exo.agenda.caldav.sync.sweep.cron:0 */5 * * * ?}") public void sweep()
      Synchronises the accounts that have gone longest without one.

      @ContainerTransactional, not the deprecated @ExoTransactional. They are not two spellings of one thing. The legacy aspect requires a container already bound to the thread and throws when there is none; this one establishes it — it reads the current container, falls back to the portal container, and runs the request lifecycle around the call. A scheduler thread is exactly the case with nothing bound, which makes the legacy annotation the wrong one on a job by construction and the right one on nothing new at all.