...
Maybe that's a question that should go out to the community?
Don't want to get into transaction management.
State/locking
How much can we guarantee?
If we do a transaction involving bits and pieces of multiple OCFL objects, it is even possible to roll that back without direct support for these sorts of transactions in the OCFL client? Probably not.
Strawman: What if an OCFL client supported such transactions like this? How could that be implemented? Is it even desirable?
- Write file content to staging places as usual
- If a failure/rollback happens here, we just have un-referenced staged content we can garbage collect later (GC)
- Maintain a database table that authoritatively OCFL metadata (that which gets written to inventory files)
- Upon "commit", copy files to the right location in OCFL
- If this fails, then these copied files can be GC'd later. They aren't referenced by any inventory files, so as far as other OCFL clients are concerned, the incompletely-copied files are invisible. That being said, the OCFL objects they've been copied to are technically invalid until these files are removed.
- Commit (or roll back) that db table. Report transaction success if that succeeds
- Asynchronously, start writing the inventory files to OCFL that references the copied content.
- If there's a failure here, that's OK. The authoritative DB still has the information in it to re-try until all the inventory files on the FS agree with the db.
TODO: Aaron Birklandflesh this out. Maybe bounce it by the OCFL community. Is an OCFL client that behaves that way "proper"?
Actions
- Danny Bernstein will reach out to Greg about DRASTIC test results
- Aaron Birkland to work with Andrew Woods to get the Go client working on travis.
...