Package org.exoplatform.caldav.entity

Class CaldavPendingPushEntity

java.lang.Object
org.exoplatform.caldav.entity.CaldavPendingPushEntity
@Entity(name="CaldavPendingPushEntity") public class CaldavPendingPushEntity extends Object
One write eXo owes a calendar copy: recorded before it is attempted, deleted when it lands, retried by the sweep until it does or until it has been refused often enough to stop.

A table of its own rather than two columns on CALDAV_OBJECT_SYNC. The mapping row was the obvious place — it is already eXo's record of what it believes it wrote — and it is the wrong one, for two reasons that both bite.

The first is that the mapping row has several writers, and every one of them saves it whole. CaldavPushService.writeInto, the deletion path and the verification pass all read a row into a detached DTO, change one field and save it back, which rewrites every column from the snapshot they read. A marker set between one of those reads and its save would be erased by it, silently — the obligation cleared by a pass that knew nothing about it. That is the read-modify-save hazard the org's backend norms describe, and the clean answer to it is not to put a second writer's state on somebody else's row.

The second is cost, and it is the constraint EXO-89716 and EXO-89756 left behind: a converged account must cost nothing. This table is empty when everything has landed, so the retry pass is one index lookup that answers no rows. A marker column on the mapping table would instead have the pass read every copy the user holds, on every sweep, to discover that none of them is owed anything.

The row is bound to the mapping by a foreign key that cascades: a copy whose mapping is gone is a copy nothing can be owed to, and an obligation that outlived its subject would be retried against an identifier that no longer resolves.

  • Constructor Details

    • CaldavPendingPushEntity

      public CaldavPendingPushEntity()