The basic variants of the time-stamp based method of concurrency control are:

Concept. Timestamp-based concurrency control replaces locking with a clock. Every transaction is stamped at its start with a unique, monotonically increasing value TS(T), and the scheduler's whole job is to keep accesses to a granule in the order of those stamps: of two conflicting accesses, the one issued by the older transaction must appear to have happened first. A transaction that would violate that order is never made to wait — it is aborted and restarted — so the family is deadlock-free by construction and its practical cost is paid in aborts rather than in blocking.

Concept — how the family is organised. Every member enforces that same timestamp rule, so the members are told apart by two coupled things: what the scheduler stores for each granule, and what test it applies to an arriving access. Reading the three named methods along those two axes — the per-granule state, then the rule that state makes possible — is what separates them.

Application. Take each method named in this item along those two axes:

1. Total time stamp ordering — a single timestamp per granule. No distinction is made between read and write access, so every conflicting access must be kept in timestamp order and a transaction involved in a violating access is aborted. It is the cheapest in storage and the most abort-prone.

2. Partial time stamp ordering — a read timestamp and a write timestamp per granule. Only the non-permutable actions are ordered: a granule may be read by any transaction younger than the transaction that last updated it, and a transaction is aborted when it tries to update a granule already accessed by a younger transaction. It aborts fewer transactions than the total scheme, at the cost of the extra granule timestamp.

3. Multiversion time stamp ordering — a chain of timestamped versions per granule. Every update creates a new version carrying its own granule timestamp, and a reader is not tested against a single current copy at all: it is served the youngest version older than itself, so it sees a consistent set of versions and is answered out of stored history.

Cross-check. The three are separately documented members of one family, told apart by the per-granule state they keep — a single timestamp, a read/write timestamp pair, or a chain of versions — and by the access rule that state makes possible. None of them is a locking, optimistic or validation-based scheme wearing a timestamp name, and none is a renaming of another. Because all three belong to the family the stem asks about, the completion that covers the whole set — “All of the above” — is what the item wants; naming a single scheme would leave out two that are equally basic variants of the same timestamp-based approach.