Page History

...

The task will thus fail only if the checksums differ, which can only happen if some part of the Item (metadata or bitstream) itself differs. If the version of the item that is believed to be authentic is the repository (local) one, then a simple performance of 'transmitAIP' task on the item will restore synchrony. For collections and communities, this task also does an 'extent' comparison, which means that it will determine whether the replica store has an AIP for every item known (locally) to be in the collection or community.

Repairing Damage

The AIPs in the replica store represent an insurance policy, and when 'claims' against that policy are filed, they can cover 2 situations: either the repository object is completely missing, and we want to restore it, or it is damaged and we want to repair the damage with data from the replica store AIP. A pair of replication tasks perform these functions: 'org.dspace.ctask.replicate.RecoverFromAIP' will do the following:

• fetch the replica store AIP for the identifier given the task
• decompress it and create a new DSpace object
• install the object into the repository, including restoring it's state (withdrawn, embargoed, etc)

This task will fail if there is already an object in the repository bearing the identifier given. By contrast, the task 'org.dspace.ctask.replicate.ReplaceWithAIP' (the 'repair' task), expects an existing repository object, and will fail if it does not find one. This task simply 'overlays' the metadata and bitstreams of the AIP version onto the existing record.

Cleanup