This page is intended to help define requirements for API-level locking support in Fedora.

; NOTE: A specific locking solution has been proposed. See CoreDev__LockingProposal.

Current Situation

As of version 2.1.1, Fedora's API has not supported any form of locking. Each API call represents a single atomic unit of work. Locking at the API level would allow applications to work with Fedora in a more transactional way.

Granularity

People seem to be gravitating toward "atomistic" content models, so locking at the object level seems most useful. Lower level locking would probably involve significant re-thinking about how objects' primary copies are stored: the FOXML contains all components...how would we lock "parts" of a FOXML file, for example?

Lock Types

Exclusive locks would preclude others from reading or writing while held.
Shared locks would preclude writes while held.

Do we support exclusive only, or both?

Other ideas?

Avoiding Deadlock

Timeouts: server or client controlled? Both?

Scope

Should FieldSearch and RISearch be locked while an exclusive lock is in play?

API Exposure

Locking

Identify one object, or a set of objects to lock at one time?

Cascading lock via some RELS-EXT property? (levels? avoid loops!)

Unlocking

Given that we don't really have the notion of an API-level "session" in Fedora, how do we expose the locking/unlocking in such a way that multiple parties don't/can't step on each other's releasing of locks?

i.e. Party A gets a lock on some object. Party B blindly unlocks it.

Maybe associate userId with lock?

Normal case: User A acquires lock, user A is the only one who can release it.

Exceptional case: User A acquires lock, administrative user releases it because User A's gone to lunch and the timeout is configured high?

If we want to deal with exceptional case, is this controllable via XACML?