Type Members

1.  case class ActivenessCheck[Key](checkFresh: Set[Key], checkFree: Set[Key], checkActive: Set[Key], lock: Set[Key])(implicit prettyK: Pretty[Key]) extends PrettyPrinting with Product with Serializable

   Defines the activeness checks and locking for one kind of states (contracts, keys, ...)

   Defines the activeness checks and locking for one kind of states (contracts, keys, ...)

   ActivenessCheck.checkFresh, ActivenessCheck.checkFree, and ActivenessCheck.checkActive must be pairwise disjoint.

   Exceptions thrown

   java.lang.IllegalArgumentException if ActivenessCheck.checkFresh, ActivenessCheck.checkFree, and ActivenessCheck.checkActive are not pairwise disjoint.

2.  case class ActivenessCheckResult[Key, Status <: PrettyPrinting](alreadyLocked: Set[Key], notFresh: Set[Key], unknown: Set[Key], notFree: Map[Key, Status], notActive: Map[Key, Status])(implicit prettyK: Pretty[Key]) extends PrettyPrinting with Product with Serializable

   The result of the activeness check for an ActivenessCheck.

   The result of the activeness check for an ActivenessCheck. If all sets are empty, the activeness check was successful.

   alreadyLocked

   The items that have already been locked at the activeness check.

   notFresh

   The items that are supposed to not exist, but do.

   notFree

   The items that shall be free, but are not.

   notActive

   The contracts that shall be active, but are not.

3.  case class ActivenessResult(contracts: ActivenessCheckResult[LfContractId, Status], inactiveTransfers: Set[TransferId], keys: ActivenessCheckResult[LfGlobalKey, Status]) extends PrettyPrinting with Product with Serializable

   The result of the activeness check for an ActivenessSet.

   The result of the activeness check for an ActivenessSet. If all sets are empty, the activeness check was successful.

   contracts

   The contracts whose activeness check has failed

   inactiveTransfers

   The transfers that shall be completed, but that are not active.

4.  case class ActivenessSet(contracts: ActivenessCheck[LfContractId], transferIds: Set[TransferId], keys: ActivenessCheck[LfGlobalKey]) extends PrettyPrinting with Product with Serializable

   Defines the contracts and transfers for conflict detection.

   Defines the contracts and transfers for conflict detection. Transfers are not locked because the transferred contracts are already being locked.

5.  case class CommitSet(archivals: Map[LfContractId, WithContractHash[Set[LfPartyId]]], creations: Map[LfContractId, WithContractHash[ContractMetadata]], transferOuts: Map[LfContractId, WithContractHash[(DomainId, Set[LfPartyId])]], transferIns: Map[LfContractId, WithContractHash[WithContractMetadata[TransferId]]], keyUpdates: Map[LfGlobalKey, Status]) extends PrettyPrinting with Product with Serializable

   Describes the effect of a confirmation request on the active contracts, contract keys, and transfers.

   Describes the effect of a confirmation request on the active contracts, contract keys, and transfers. Transient contracts appear the following two sets:

   • The union of creations and transferIns
   • The union of archivals or transferOuts

   archivals

   The contracts to be archived, along with their stakeholders. Must not contain contracts in transferOuts.

   creations

   The contracts to be created.

   transferOuts

   The contracts to be transferred out, along with their target domains and stakeholders. Must not contain contracts in archivals.

   transferIns

   The contracts to be transferred in, along with their transfer IDs.

   keyUpdates

   The contract keys with their new state.

   Exceptions thrown

   java.lang.IllegalArgumentException if transferOuts overlap with archivals or creations overlaps with transferIns.

6.  class ConflictDetector extends NamedLogging with FlagCloseable

   The ConflictDetector stores the state of contracts activated or deactivated by in-flight requests in memory, and similarly for contract keys.

   The ConflictDetector stores the state of contracts activated or deactivated by in-flight requests in memory, and similarly for contract keys. Such states take precedence over the states stored in the ACS or the contract key journal, which are only updated when a request is finalized. A request is in flight from the call to ConflictDetector.registerActivenessSet until the corresponding call to ConflictDetector.finalizeRequest has written the updates to the ACS.

   The ConflictDetector also checks that transfer-ins refer to active transfers and atomically completes them during finalization.

7.  case class IllegalConflictDetectionStateException(msg: String, cause: Throwable = null) extends RuntimeException with Product with Serializable

   Annotations

   @SuppressWarnings()

8.  case class ImmutableLockableState[Status <: PrettyPrinting](versionedState: Option[Option[StateChange[Status]]], pendingActivenessChecks: PendingActivenessCheckCounter, lock: LockCounter, pendingWrites: PendingWriteCounter) extends LockableState[Status] with Product with Serializable
9.  trait LockableState[Status <: PrettyPrinting] extends PrettyPrinting
10.  class LockableStates[Key, Status <: PrettyPrinting with HasPrunable, E] extends NamedLogging

    Manages in-memory states of items (contracts, keys, ...) that are used or modified by in-flight requests.

    Manages in-memory states of items (contracts, keys, ...) that are used or modified by in-flight requests. Such in-memory states take precedence over the states in the underlying store, which is only updated when a request is finalized.

    Key

    Identifier for states

    Status

    The status type for states.

11.  trait LockableStatus[-Status] extends AnyRef

    Type class for operations on statuses that can be locked.

    Type class for operations on statuses that can be locked.

    Also defines the eviction strategy for items.

12.  class MutableLockableState[Status <: PrettyPrinting] extends LockableState[Status] with PrettyPrinting

    A mutable lockable in-memory state with support for pre-fetching from a store

13.  class NaiveRequestTracker extends RequestTracker with NamedLogging with FlagCloseableAsync

    The naive request tracker performs all its tasks (activeness check/timeout/finalization) sequentially.

    The naive request tracker performs all its tasks (activeness check/timeout/finalization) sequentially. It accumulates all pending tasks in a priority queue and executes them as soon as the request tracker can progress to their associated timestamp. The execution happens asynchronously in the execution context ecForConflictDetection.

    Requests are kept in memory from the call to NaiveRequestTracker!.addRequest until the finalization time or the timeout.

14.  trait RequestTracker extends AutoCloseable with NamedLogging

    The request tracker handles all the tasks around conflict detection that are difficult to parallelize.

    The request tracker handles all the tasks around conflict detection that are difficult to parallelize. In detail, it tracks in-flight requests, performs activeness checks, detects conflicts between requests, keeps track of the sequencer time, checks for timeouts, and orchestrates the updates to the com.digitalasset.canton.participant.store.ActiveContractStore. It does not write to the com.digitalasset.canton.participant.protocol.RequestJournal, though. The request tracker lives entirely in memory on a single compute node.

    The request tracker is a deterministic component that depends only on the ACS state and the sequencer messages. The order and timing in which the request tracker receives this information does not matter. (Even more broadly, the participant has no functional notion of “wall-clock” time; all time and timestamps come from sequencer messages.) These properties of determinism and sequencer time are both important parts of Canton and critical to the crash recovery model.

    To keep track of the sequencer time, the request tracker must be notified of every message that is received from the sequencer. These notifications need not happen in order, but they must happen eventually. Every such message has an associated monotonically increasing SequencerCounter. If one of the sequencer counters is skipped, the request tracker may stall indefinitely. Every message has an associated timestamp. Time must increase with every message in the order given by the sequencer counter. This means that for sequencer counters sc1 and sc2 with sc1 < sc2, the associated timestamps ts1 and ts2 must satisfy ts1 < ts2.

    Requests are identified by RequestCounters, which themselves must be a monotonically increasing sequence without gaps.

    The request tracker uses these time signals to determine on which requests a verdict can be issued, which requests have timed out, and which requests and contract states can be safely evicted from the tracker's internal state. We say that the request tracker has observed a timestamp if it has been signalled this timestamp or a later one. The request tracker can progress to a timestamp ts if it has observed all timestamps up to and including ts and all commit sets with commit times up to ts have been added with RequestTracker.addCommitSet.

    If the request tracker can progress to a timestamp ts, then it must eventually complete all futures that RequestTracker.addRequest and RequestTracker.addCommitSet have returned and that are associated with a timestamp equal or prior to ts. The futures are associated to the following timestamps:

    • Activeness result: the activeness time of the request, typically the timestamp on the request
    • Timeout result: the decision time of the request
    • Finalization result: the commit time of the request

    The three methods RequestTracker.addRequest, RequestTracker.addResult, and RequestTracker.addCommitSet must normally be called in the given sequence; the latter two need not be called if the request has timed out. A request is in flight from the corresponding call to RequestTracker.addRequest until the request tracker has progressed to its decision time (if the request times out) or its commit time.

    These three methods are idempotent while the request is in flight. That is, if one of the methods is called twice with the same arguments, provided that the first one succeeded, then the second call has no effect, but its return value is equivalent to what the first call returned. If the method is called twice for the same request counter with different arguments, the subsequent behavior of the request tracker becomes unspecified. The same applies if the same sequencer counter is supplied several times with different timestamps.

    A request tracker is typically initialized with a SequencerCounter and a com.digitalasset.canton.data.CantonTimestamp, causing it to be ready to handle requests starting from the given sequencer counter (inclusive) and timestamp (exclusive).

    Conflict detection

    The request tracker checks whether a request uses only contracts that are active at the activeness timestamp of the request. To that end, it determines the ActivenessResult of the request. A non-conflicting request should be approved in a response by the participant. A conflicting request should be rejected.

    To describe conflict behavior, we introduce a few concepts:

    A conflict detection time is a triple (com.digitalasset.canton.data.CantonTimestamp, Kind, SequencerCounter). There are four kinds, and they are ordered by

    Result < Finalize < Request < Timeout

    . Conflict detection times are ordered lexicographically. In other words,

    (ts1, kind1, sc1) < (ts2, kind2, sc2)

    if and only if

    ts1 < ts2

    or

    ts1 == ts2 && kind1 < kind2

    or

    ts1 == ts2 && kind1 == kind2 && sc1 < sc2.

    A request with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts induces two conflict detection times: The sequencing time at (ts, ConfirmationRequest, sc) and the timeout time at (decisionTime, Timeout, sc) where decisionTime is the decision time of the request. Without logical reordering, the sequencing time is also the request's activeness time. (Technically, the activeness time must lie between the sequencing time and the decision time; see RequestTracker.addRequest.) A result with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts also defines two conflict detection times: The verdict time (ts, Result, sc) and the finalization time (commitTime, Finalize, sc) where commitTime is the commit time of the request.

    A request is active at some conflict detection time t if all of the following holds:

    • Its sequencing time is equal or prior to t.
    • If no finalization time is known for the request, then t is equal or prior to the request's timeout time.
    • If a finalization time is known for the request, then t is equal or prior to the finalization time.

    The finalization time of a request is known if the result has been successfully signalled to the request tracker using RequestTracker.addResult.

    A request is finalized at some conflict detection time t if its finalization time is known and equal or prior to t.

    A contract is active at time t if a request with activeness time at most t activates it, and there is no finalized request at time t that has deactivated it. Activation happens through creation and transfer-in. Deactivation happens through archival and transfer-out. An active contract is locked at time t if one of the following cases holds:

    • There is an active request at time t that activates t. In that case, we say that the contract is in activation.
    • There is an active request at time t that deactivates t and the request does not activate the contract.

    A contract may be locked because of activation and deactivation at the same time if there are two active requests, one activating the contract and another deactivating it. For example, if one request r1 creates a contract with sequencing time t1 and finalization time t1' and another request r2 with sequencing time t2 between t1 and r2 archives it (despite that r2's activeness check fails), then the contract is created at time t1 and archived at t2.

    Activeness of contracts is checked at the request's activeness time. The ActivenessResult lists all contracts from the ActivenessSet of the request that are either locked or whose precondition fails. The activeness check succeeds if the activeness result is empty.

    ts1 == ts2 && kind1 < kind2 }}}

    A request with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts induces two conflict detection times: The sequencing time at (ts, ConfirmationRequest, sc) and the timeout time at (decisionTime, Timeout, sc) where decisionTime is the decision time of the request. Without logical reordering, the sequencing time is also the request's activeness time. (Technically, the activeness time must lie between the sequencing time and the decision time; see RequestTracker.addRequest.) A result with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts also defines two conflict detection times: The verdict time (ts, Result, sc) and the finalization time (commitTime, Finalize, sc) where commitTime is the commit time of the request.

    A request is active at some conflict detection time t if all of the following holds:

    • Its sequencing time is equal or prior to t.
    • If no finalization time is known for the request, then t is equal or prior to the request's timeout time.
    • If a finalization time is known for the request, then t is equal or prior to the finalization time.

    The finalization time of a request is known if the result has been successfully signalled to the request tracker using RequestTracker.addResult.

    A request is finalized at some conflict detection time t if its finalization time is known and equal or prior to t.

    A contract is active at time t if a request with activeness time at most t activates it, and there is no finalized request at time t that has deactivated it. Activation happens through creation and transfer-in. Deactivation happens through archival and transfer-out. An active contract is locked at time t if one of the following cases holds:

    • There is an active request at time t that activates t. In that case, we say that the contract is in activation.
    • There is an active request at time t that deactivates t and the request does not activate the contract.

    A contract may be locked because of activation and deactivation at the same time if there are two active requests, one activating the contract and another deactivating it. For example, if one request r1 creates a contract with sequencing time t1 and finalization time t1' and another request r2 with sequencing time t2 between t1 and r2 archives it (despite that r2's activeness check fails), then the contract is created at time t1 and archived at t2.

    Activeness of contracts is checked at the request's activeness time. The ActivenessResult lists all contracts from the ActivenessSet of the request that are either locked or whose precondition fails. The activeness check succeeds if the activeness result is empty.

    ts1 < ts2 }}}

    A request with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts induces two conflict detection times: The sequencing time at (ts, ConfirmationRequest, sc) and the timeout time at (decisionTime, Timeout, sc) where decisionTime is the decision time of the request. Without logical reordering, the sequencing time is also the request's activeness time. (Technically, the activeness time must lie between the sequencing time and the decision time; see RequestTracker.addRequest.) A result with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts also defines two conflict detection times: The verdict time (ts, Result, sc) and the finalization time (commitTime, Finalize, sc) where commitTime is the commit time of the request.

    A request is active at some conflict detection time t if all of the following holds:

    • Its sequencing time is equal or prior to t.
    • If no finalization time is known for the request, then t is equal or prior to the request's timeout time.
    • If a finalization time is known for the request, then t is equal or prior to the finalization time.

    The finalization time of a request is known if the result has been successfully signalled to the request tracker using RequestTracker.addResult.

    A request is finalized at some conflict detection time t if its finalization time is known and equal or prior to t.

    A contract is active at time t if a request with activeness time at most t activates it, and there is no finalized request at time t that has deactivated it. Activation happens through creation and transfer-in. Deactivation happens through archival and transfer-out. An active contract is locked at time t if one of the following cases holds:

    • There is an active request at time t that activates t. In that case, we say that the contract is in activation.
    • There is an active request at time t that deactivates t and the request does not activate the contract.

    A contract may be locked because of activation and deactivation at the same time if there are two active requests, one activating the contract and another deactivating it. For example, if one request r1 creates a contract with sequencing time t1 and finalization time t1' and another request r2 with sequencing time t2 between t1 and r2 archives it (despite that r2's activeness check fails), then the contract is created at time t1 and archived at t2.

    Activeness of contracts is checked at the request's activeness time. The ActivenessResult lists all contracts from the ActivenessSet of the request that are either locked or whose precondition fails. The activeness check succeeds if the activeness result is empty.

    (ts1, kind1, sc1) < (ts2, kind2, sc2) }}}

    ts1 < ts2

    or

    ts1 == ts2 && kind1 < kind2

    or

    ts1 == ts2 && kind1 == kind2 && sc1 < sc2.

    A request with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts induces two conflict detection times: The sequencing time at (ts, ConfirmationRequest, sc) and the timeout time at (decisionTime, Timeout, sc) where decisionTime is the decision time of the request. Without logical reordering, the sequencing time is also the request's activeness time. (Technically, the activeness time must lie between the sequencing time and the decision time; see RequestTracker.addRequest.) A result with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts also defines two conflict detection times: The verdict time (ts, Result, sc) and the finalization time (commitTime, Finalize, sc) where commitTime is the commit time of the request.

    A request is active at some conflict detection time t if all of the following holds:

    • Its sequencing time is equal or prior to t.
    • If no finalization time is known for the request, then t is equal or prior to the request's timeout time.
    • If a finalization time is known for the request, then t is equal or prior to the finalization time.

    The finalization time of a request is known if the result has been successfully signalled to the request tracker using RequestTracker.addResult.

    A request is finalized at some conflict detection time t if its finalization time is known and equal or prior to t.

    A contract is active at time t if a request with activeness time at most t activates it, and there is no finalized request at time t that has deactivated it. Activation happens through creation and transfer-in. Deactivation happens through archival and transfer-out. An active contract is locked at time t if one of the following cases holds:

    • There is an active request at time t that activates t. In that case, we say that the contract is in activation.
    • There is an active request at time t that deactivates t and the request does not activate the contract.

    A contract may be locked because of activation and deactivation at the same time if there are two active requests, one activating the contract and another deactivating it. For example, if one request r1 creates a contract with sequencing time t1 and finalization time t1' and another request r2 with sequencing time t2 between t1 and r2 archives it (despite that r2's activeness check fails), then the contract is created at time t1 and archived at t2.

    Activeness of contracts is checked at the request's activeness time. The ActivenessResult lists all contracts from the ActivenessSet of the request that are either locked or whose precondition fails. The activeness check succeeds if the activeness result is empty.

    ts1 == ts2 && kind1 < kind2 }}}

    A request with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts induces two conflict detection times: The sequencing time at (ts, ConfirmationRequest, sc) and the timeout time at (decisionTime, Timeout, sc) where decisionTime is the decision time of the request. Without logical reordering, the sequencing time is also the request's activeness time. (Technically, the activeness time must lie between the sequencing time and the decision time; see RequestTracker.addRequest.) A result with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts also defines two conflict detection times: The verdict time (ts, Result, sc) and the finalization time (commitTime, Finalize, sc) where commitTime is the commit time of the request.

    A request is active at some conflict detection time t if all of the following holds:

    • Its sequencing time is equal or prior to t.
    • If no finalization time is known for the request, then t is equal or prior to the request's timeout time.
    • If a finalization time is known for the request, then t is equal or prior to the finalization time.

    The finalization time of a request is known if the result has been successfully signalled to the request tracker using RequestTracker.addResult.

    A request is finalized at some conflict detection time t if its finalization time is known and equal or prior to t.

    A contract is active at time t if a request with activeness time at most t activates it, and there is no finalized request at time t that has deactivated it. Activation happens through creation and transfer-in. Deactivation happens through archival and transfer-out. An active contract is locked at time t if one of the following cases holds:

    • There is an active request at time t that activates t. In that case, we say that the contract is in activation.
    • There is an active request at time t that deactivates t and the request does not activate the contract.

    A contract may be locked because of activation and deactivation at the same time if there are two active requests, one activating the contract and another deactivating it. For example, if one request r1 creates a contract with sequencing time t1 and finalization time t1' and another request r2 with sequencing time t2 between t1 and r2 archives it (despite that r2's activeness check fails), then the contract is created at time t1 and archived at t2.

    Activeness of contracts is checked at the request's activeness time. The ActivenessResult lists all contracts from the ActivenessSet of the request that are either locked or whose precondition fails. The activeness check succeeds if the activeness result is empty.

    ts1 < ts2 }}}

    A request with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts induces two conflict detection times: The sequencing time at (ts, ConfirmationRequest, sc) and the timeout time at (decisionTime, Timeout, sc) where decisionTime is the decision time of the request. Without logical reordering, the sequencing time is also the request's activeness time. (Technically, the activeness time must lie between the sequencing time and the decision time; see RequestTracker.addRequest.) A result with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts also defines two conflict detection times: The verdict time (ts, Result, sc) and the finalization time (commitTime, Finalize, sc) where commitTime is the commit time of the request.

    A request is active at some conflict detection time t if all of the following holds:

    • Its sequencing time is equal or prior to t.
    • If no finalization time is known for the request, then t is equal or prior to the request's timeout time.
    • If a finalization time is known for the request, then t is equal or prior to the finalization time.

    The finalization time of a request is known if the result has been successfully signalled to the request tracker using RequestTracker.addResult.

    A request is finalized at some conflict detection time t if its finalization time is known and equal or prior to t.

    A contract is active at time t if a request with activeness time at most t activates it, and there is no finalized request at time t that has deactivated it. Activation happens through creation and transfer-in. Deactivation happens through archival and transfer-out. An active contract is locked at time t if one of the following cases holds:

    • There is an active request at time t that activates t. In that case, we say that the contract is in activation.
    • There is an active request at time t that deactivates t and the request does not activate the contract.

    A contract may be locked because of activation and deactivation at the same time if there are two active requests, one activating the contract and another deactivating it. For example, if one request r1 creates a contract with sequencing time t1 and finalization time t1' and another request r2 with sequencing time t2 between t1 and r2 archives it (despite that r2's activeness check fails), then the contract is created at time t1 and archived at t2.

    Activeness of contracts is checked at the request's activeness time. The ActivenessResult lists all contracts from the ActivenessSet of the request that are either locked or whose precondition fails. The activeness check succeeds if the activeness result is empty.

    Result < Finalize < Request < Timeout }}} Conflict detection times are ordered lexicographically. In other words,

    (ts1, kind1, sc1) < (ts2, kind2, sc2)

    if and only if

    ts1 < ts2

    or

    ts1 == ts2 && kind1 < kind2

    or

    ts1 == ts2 && kind1 == kind2 && sc1 < sc2.

    A request with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts induces two conflict detection times: The sequencing time at (ts, ConfirmationRequest, sc) and the timeout time at (decisionTime, Timeout, sc) where decisionTime is the decision time of the request. Without logical reordering, the sequencing time is also the request's activeness time. (Technically, the activeness time must lie between the sequencing time and the decision time; see RequestTracker.addRequest.) A result with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts also defines two conflict detection times: The verdict time (ts, Result, sc) and the finalization time (commitTime, Finalize, sc) where commitTime is the commit time of the request.

    A request is active at some conflict detection time t if all of the following holds:

    • Its sequencing time is equal or prior to t.
    • If no finalization time is known for the request, then t is equal or prior to the request's timeout time.
    • If a finalization time is known for the request, then t is equal or prior to the finalization time.

    The finalization time of a request is known if the result has been successfully signalled to the request tracker using RequestTracker.addResult.

    A request is finalized at some conflict detection time t if its finalization time is known and equal or prior to t.

    A contract is active at time t if a request with activeness time at most t activates it, and there is no finalized request at time t that has deactivated it. Activation happens through creation and transfer-in. Deactivation happens through archival and transfer-out. An active contract is locked at time t if one of the following cases holds:

    • There is an active request at time t that activates t. In that case, we say that the contract is in activation.
    • There is an active request at time t that deactivates t and the request does not activate the contract.

    A contract may be locked because of activation and deactivation at the same time if there are two active requests, one activating the contract and another deactivating it. For example, if one request r1 creates a contract with sequencing time t1 and finalization time t1' and another request r2 with sequencing time t2 between t1 and r2 archives it (despite that r2's activeness check fails), then the contract is created at time t1 and archived at t2.

    Activeness of contracts is checked at the request's activeness time. The ActivenessResult lists all contracts from the ActivenessSet of the request that are either locked or whose precondition fails. The activeness check succeeds if the activeness result is empty.

    ts1 == ts2 && kind1 < kind2 }}}

    A request with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts induces two conflict detection times: The sequencing time at (ts, ConfirmationRequest, sc) and the timeout time at (decisionTime, Timeout, sc) where decisionTime is the decision time of the request. Without logical reordering, the sequencing time is also the request's activeness time. (Technically, the activeness time must lie between the sequencing time and the decision time; see RequestTracker.addRequest.) A result with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts also defines two conflict detection times: The verdict time (ts, Result, sc) and the finalization time (commitTime, Finalize, sc) where commitTime is the commit time of the request.

    A request is active at some conflict detection time t if all of the following holds:

    • Its sequencing time is equal or prior to t.
    • If no finalization time is known for the request, then t is equal or prior to the request's timeout time.
    • If a finalization time is known for the request, then t is equal or prior to the finalization time.

    The finalization time of a request is known if the result has been successfully signalled to the request tracker using RequestTracker.addResult.

    A request is finalized at some conflict detection time t if its finalization time is known and equal or prior to t.

    A contract is active at time t if a request with activeness time at most t activates it, and there is no finalized request at time t that has deactivated it. Activation happens through creation and transfer-in. Deactivation happens through archival and transfer-out. An active contract is locked at time t if one of the following cases holds:

    • There is an active request at time t that activates t. In that case, we say that the contract is in activation.
    • There is an active request at time t that deactivates t and the request does not activate the contract.

    A contract may be locked because of activation and deactivation at the same time if there are two active requests, one activating the contract and another deactivating it. For example, if one request r1 creates a contract with sequencing time t1 and finalization time t1' and another request r2 with sequencing time t2 between t1 and r2 archives it (despite that r2's activeness check fails), then the contract is created at time t1 and archived at t2.

    Activeness of contracts is checked at the request's activeness time. The ActivenessResult lists all contracts from the ActivenessSet of the request that are either locked or whose precondition fails. The activeness check succeeds if the activeness result is empty.

    ts1 < ts2 }}}

    A request with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts induces two conflict detection times: The sequencing time at (ts, ConfirmationRequest, sc) and the timeout time at (decisionTime, Timeout, sc) where decisionTime is the decision time of the request. Without logical reordering, the sequencing time is also the request's activeness time. (Technically, the activeness time must lie between the sequencing time and the decision time; see RequestTracker.addRequest.) A result with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts also defines two conflict detection times: The verdict time (ts, Result, sc) and the finalization time (commitTime, Finalize, sc) where commitTime is the commit time of the request.

    A request is active at some conflict detection time t if all of the following holds:

    • Its sequencing time is equal or prior to t.
    • If no finalization time is known for the request, then t is equal or prior to the request's timeout time.
    • If a finalization time is known for the request, then t is equal or prior to the finalization time.

    The finalization time of a request is known if the result has been successfully signalled to the request tracker using RequestTracker.addResult.

    A request is finalized at some conflict detection time t if its finalization time is known and equal or prior to t.

    A contract is active at time t if a request with activeness time at most t activates it, and there is no finalized request at time t that has deactivated it. Activation happens through creation and transfer-in. Deactivation happens through archival and transfer-out. An active contract is locked at time t if one of the following cases holds:

    • There is an active request at time t that activates t. In that case, we say that the contract is in activation.
    • There is an active request at time t that deactivates t and the request does not activate the contract.

    A contract may be locked because of activation and deactivation at the same time if there are two active requests, one activating the contract and another deactivating it. For example, if one request r1 creates a contract with sequencing time t1 and finalization time t1' and another request r2 with sequencing time t2 between t1 and r2 archives it (despite that r2's activeness check fails), then the contract is created at time t1 and archived at t2.

    Activeness of contracts is checked at the request's activeness time. The ActivenessResult lists all contracts from the ActivenessSet of the request that are either locked or whose precondition fails. The activeness check succeeds if the activeness result is empty.

    (ts1, kind1, sc1) < (ts2, kind2, sc2) }}}

    ts1 < ts2

    or

    ts1 == ts2 && kind1 < kind2

    or

    ts1 == ts2 && kind1 == kind2 && sc1 < sc2.

    A request with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts induces two conflict detection times: The sequencing time at (ts, ConfirmationRequest, sc) and the timeout time at (decisionTime, Timeout, sc) where decisionTime is the decision time of the request. Without logical reordering, the sequencing time is also the request's activeness time. (Technically, the activeness time must lie between the sequencing time and the decision time; see RequestTracker.addRequest.) A result with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts also defines two conflict detection times: The verdict time (ts, Result, sc) and the finalization time (commitTime, Finalize, sc) where commitTime is the commit time of the request.

    A request is active at some conflict detection time t if all of the following holds:

    • Its sequencing time is equal or prior to t.
    • If no finalization time is known for the request, then t is equal or prior to the request's timeout time.
    • If a finalization time is known for the request, then t is equal or prior to the finalization time.

    The finalization time of a request is known if the result has been successfully signalled to the request tracker using RequestTracker.addResult.

    A request is finalized at some conflict detection time t if its finalization time is known and equal or prior to t.

    A contract is active at time t if a request with activeness time at most t activates it, and there is no finalized request at time t that has deactivated it. Activation happens through creation and transfer-in. Deactivation happens through archival and transfer-out. An active contract is locked at time t if one of the following cases holds:

    • There is an active request at time t that activates t. In that case, we say that the contract is in activation.
    • There is an active request at time t that deactivates t and the request does not activate the contract.

    A contract may be locked because of activation and deactivation at the same time if there are two active requests, one activating the contract and another deactivating it. For example, if one request r1 creates a contract with sequencing time t1 and finalization time t1' and another request r2 with sequencing time t2 between t1 and r2 archives it (despite that r2's activeness check fails), then the contract is created at time t1 and archived at t2.

    Activeness of contracts is checked at the request's activeness time. The ActivenessResult lists all contracts from the ActivenessSet of the request that are either locked or whose precondition fails. The activeness check succeeds if the activeness result is empty.

    ts1 == ts2 && kind1 < kind2 }}}

    A request with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts induces two conflict detection times: The sequencing time at (ts, ConfirmationRequest, sc) and the timeout time at (decisionTime, Timeout, sc) where decisionTime is the decision time of the request. Without logical reordering, the sequencing time is also the request's activeness time. (Technically, the activeness time must lie between the sequencing time and the decision time; see RequestTracker.addRequest.) A result with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts also defines two conflict detection times: The verdict time (ts, Result, sc) and the finalization time (commitTime, Finalize, sc) where commitTime is the commit time of the request.

    A request is active at some conflict detection time t if all of the following holds:

    • Its sequencing time is equal or prior to t.
    • If no finalization time is known for the request, then t is equal or prior to the request's timeout time.
    • If a finalization time is known for the request, then t is equal or prior to the finalization time.

    The finalization time of a request is known if the result has been successfully signalled to the request tracker using RequestTracker.addResult.

    A request is finalized at some conflict detection time t if its finalization time is known and equal or prior to t.

    A contract is active at time t if a request with activeness time at most t activates it, and there is no finalized request at time t that has deactivated it. Activation happens through creation and transfer-in. Deactivation happens through archival and transfer-out. An active contract is locked at time t if one of the following cases holds:

    • There is an active request at time t that activates t. In that case, we say that the contract is in activation.
    • There is an active request at time t that deactivates t and the request does not activate the contract.

    A contract may be locked because of activation and deactivation at the same time if there are two active requests, one activating the contract and another deactivating it. For example, if one request r1 creates a contract with sequencing time t1 and finalization time t1' and another request r2 with sequencing time t2 between t1 and r2 archives it (despite that r2's activeness check fails), then the contract is created at time t1 and archived at t2.

    Activeness of contracts is checked at the request's activeness time. The ActivenessResult lists all contracts from the ActivenessSet of the request that are either locked or whose precondition fails. The activeness check succeeds if the activeness result is empty.

    ts1 < ts2 }}}

    A request with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts induces two conflict detection times: The sequencing time at (ts, ConfirmationRequest, sc) and the timeout time at (decisionTime, Timeout, sc) where decisionTime is the decision time of the request. Without logical reordering, the sequencing time is also the request's activeness time. (Technically, the activeness time must lie between the sequencing time and the decision time; see RequestTracker.addRequest.) A result with SequencerCounter sc and com.digitalasset.canton.data.CantonTimestamp ts also defines two conflict detection times: The verdict time (ts, Result, sc) and the finalization time (commitTime, Finalize, sc) where commitTime is the commit time of the request.

    A request is active at some conflict detection time t if all of the following holds:

    • Its sequencing time is equal or prior to t.
    • If no finalization time is known for the request, then t is equal or prior to the request's timeout time.
    • If a finalization time is known for the request, then t is equal or prior to the finalization time.

    The finalization time of a request is known if the result has been successfully signalled to the request tracker using RequestTracker.addResult.

    A request is finalized at some conflict detection time t if its finalization time is known and equal or prior to t.

    A contract is active at time t if a request with activeness time at most t activates it, and there is no finalized request at time t that has deactivated it. Activation happens through creation and transfer-in. Deactivation happens through archival and transfer-out. An active contract is locked at time t if one of the following cases holds:

    • There is an active request at time t that activates t. In that case, we say that the contract is in activation.
    • There is an active request at time t that deactivates t and the request does not activate the contract.

    A contract may be locked because of activation and deactivation at the same time if there are two active requests, one activating the contract and another deactivating it. For example, if one request r1 creates a contract with sequencing time t1 and finalization time t1' and another request r2 with sequencing time t2 between t1 and r2 archives it (despite that r2's activeness check fails), then the contract is created at time t1 and archived at t2.

    Activeness of contracts is checked at the request's activeness time. The ActivenessResult lists all contracts from the ActivenessSet of the request that are either locked or whose precondition fails. The activeness check succeeds if the activeness result is empty.