Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Delete File Communication uses the general communication pattern with an IdentifyPillarsForDelete and a Delete Primitive. May also include a confirmation, finalisation and Undelete part. To be analysed.

Delete File communication starts as the general communication pattern

  • Client sends IdentifyPillarsForDeleteFileRequest message with FileID, and all pillars which have files for the bit repository collection reply with IdentifyPillarsForDeleteFileResponse messages
  • Client sends DeleteFileRequest messages with FileID to the relevant identified pillars and all pillars in reply with DeleteFileProgressResponse 

    It is not currently decided whether data will now be deleted on the specified pillar or on the repository and DeleteFileFinalResponse messages sent, or do we want a two-phase commit where the data is now in an 'under deletion state' and the client must send a delete confirmation before the pillars finalise the deletion.

Note that delete can either be of

  • all replicas
  • of a specific replica

The difference is made in the choice of whioch pilars to send the DeleteFileRequest

See also Undelete under Delete Design Discussions

  • No labels