Table of Contents

This proposal is for a simple, per-object, EXCLUSIVE locking mechanism for Fedora.

Benefits

  • Improved atomicity: Still per-object, but no longer limited to per-method.
  • Isolation: from in-progress changes to an object. Readers must wait for an object modification to be committed (or rolled back) before accessing the object.
  • Performance: While making multiple changes to one object, the overhead of database and triplestore index updating can be pushed to the end of the "transaction".

; Note: While this will enable certain multi-object update scenarios, it will not cover all of them. For example, imagine locking two objects, a bdef and a regular data object. The bdef is modified, but not yet committed. The data object will not "see" the change to the bdef until it is committed.

API Methods

For explicit locking, two new API-M methods are proposed:

; Getting a lock: lockObject(String pid)
; Releasing a lock: unlockObject(String pid, boolean commit)

Implicit locks will be automatically obtained during the course of executing an API-M modification method if the object being modified is not already explicitly locked.

; Note: Locks are short-lived and exclusive: While held and not timed out, reads must wait (or timeout on client or server end).

Implementation Notes

For explicit locks, in order to support isolation and rollback:

  • The database and any indexes (e.g. kowari) are not updated until final commit time.
  • When an explicit lock is started, the original FOXML is backed up.
  • Modifications to the FOXML within the context of the lock are carried out in-place.
  • Modifications (versioning) to managed datastreams are made in-place.
  • Replaces and purges of originally-present managed datastreams cause a backup to be made (for rollback).

In the event of commit:

  • The database and any indexes (e.g. kowari) are updated.
    • Q: Can the database indexes be updated in a single operation (replicate?)
  • The exclusive lock is released.
  • Backups of replaced/purged managed datastreams are deleted.

In the event of rollback:

  • The backed-up FOXML is copied over the aborted copy.
  • Backups of purged managed datastreams are put back in their original place.
  • The exlusive lock is released.
  • Any NEW managed datastream revisions are deleted from lowlevel storage.
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels