Chapter 19Transaction Model

This chapter specifies how GQL groups procedure executions into transactions and how their combined effects are applied to the shared store state. We formalize commit and rollback behavior and the visibility of intermediate updates. The GQL core assumes serializable transactional behavior; less restrictive isolation levels and their snapshot rules are implementation-defined extensions. The treatment of errors and aborts is integrated with this model so that transactional guarantees are preserved during constraint enforcement and update execution.

19.1 Demarcation and Visibility

Transaction model. A transaction $\mathrm{Tx}$ is a tuple

where $u$ is the session authorization identifier under which the transaction is executed, $\mathrm{iso}$ is SERIALIZABLE in the core model or an implementation-defined isolation extension, $\stackrel{}{P¯}=⟨P_1,\dots <!--\; FUNCTION\; APPLICATION\; -->,P_m⟩$ is a finite sequence of procedure executions performed in order, and $\mathrm{SP}$ is an optional meta-model component for savepoints. Savepoints are not part of the GQL core; an implementation extension that supplies them must also define their syntax and semantics. Let $\mathrm{\Omega },{\mathrm{\Omega }}^{\prime }$ be abstract store states and $\kappa$ an exception GQLSTATUS code as described in Chapter 21. Let the abstract transaction-outcome carrier contain the distinct constructors

They denote, respectively, successful commitment, successful rollback, and a failed outcome accompanied by a rollback attempt. These constructors are distinct from the state-transition functions defined below.

Transactions and atomicity. A transaction is a delimited unit of work. A successful commit takes effect atomically with respect to recovery, while a successfully processed rollback has no lasting effect on GQL-data or the GQL-catalog. For a well-typed program $B$ within a transaction, let $\mathrm{\Delta }(B)$ denote the finite update sequence (delta) that its execution produces over $\mathrm{\Omega }$. More generally, for any procedure execution $P$ within $B$, $\mathrm{\Delta }(P)$ denotes the delta produced by that execution. For deltas, ${\mathrm{\Delta }}_1◇{\mathrm{\Delta }}_2$ denotes their ordered composition, characterized whenever the applications are defined by

Thus $◇$ composes deltas, whereas $\oplus$ applies a delta to a store state.

These equations describe successfully processed termination requests. At the committed-state boundary, all changes of a committing transaction take effect together and no changes of a successfully rolled-back transaction remain. If a transaction-termination request cannot be processed successfully, the state of the GQL-catalog and GQL-data becomes indeterminate; how the success or failure status is made available is implementation-defined. This recovery atomicity is distinct from isolation: an implementation-defined relaxation of serializable behavior may permit some provisional changes to be perceived by a concurrent transaction.

Statement sequencing. Within a transaction, statements execute in program order; effects of each completed statement are visible to subsequent statements of the same transaction prior to commit.

Procedure-kind and working-graph restrictions. Without optional Feature GP18, mixing a catalog-modifying procedure and a data-modifying procedure in one transaction raises 25G02. Without optional Feature GT03, accessing a graph different from one already accessed in the transaction raises 25G04.

Commands. A command is an operation not specified by a procedure written in GQL.

Syntactic form of transaction control commands. At the concrete-syntax level, GQL provides dedicated commands to start, commit, and roll back transactions, with a standardized access mode and optional implementation-defined transaction modes. In a simplified BNF these commands are written as:

start-transaction-cmd ::= "START" "TRANSACTION" [ tx-characteristics ]
tx-characteristics ::= tx-mode { "," tx-mode }
tx-mode ::= tx-access-mode | impl-defined-mode
tx-access-mode ::= "READ" "ONLY" | "READ" "WRITE"
commit-cmd ::= "COMMIT"
rollback-cmd ::= "ROLLBACK"
impl-defined-mode ::= ...

The syntax requires exactly one transaction access mode. Additional modes, including any means of selecting a less restrictive isolation level, are implementation-defined. Explicit transaction commands require optional Feature GT01, and explicit transaction characteristics require optional Feature GT02. If the characteristics are omitted, an implementation-defined (ID006) default characteristic is implicit and contains READ WRITE.

Begin/commit/rollback. A transaction may begin in either of two ways. It is initiated explicitly by START TRANSACTION, optionally with characteristics, or, if none is active, implicitly at the commencement of executing a procedure. It may contain a sequence of procedure executions and is terminated by an attempt to COMMIT or ROLLBACK. On a successful COMMIT the system applies $\mathrm{\Delta }(B)$ atomically to $\mathrm{\Omega }$. If the transaction is part of an encompassing transaction controlled by another agent, 2D000 is raised. If any other error prevents commitment, all changes are canceled and 40000 is raised with an implementation-defined subclass. An explicit ROLLBACK likewise raises 2D000 rather than canceling changes when such an encompassing transaction is controlled by another agent; otherwise, all changes made by the active transaction are canceled.

Example: transaction tuple and COMMIT boundary. Let alice be the session authorization identifier and let $P_{\mathrm{fees}}$ be the procedure execution denoted by the call in Line 13. Then, in the abstract serializable transaction model used here, an explicitly demarcated transaction can be represented by

A corresponding GQL-program transaction activity is:

START TRANSACTION READ WRITE
CALL recomputeFees(DATE '2025-12-31')
YIELD updatedCount AS cnt
COMMIT

The COMMIT command requests termination of the transaction by commit; it is not an element of the procedure-execution sequence $\stackrel{}{P¯}$.

Visibility. For the serializable behavior assumed by the GQL core, concurrent activity is observed as a serial order. Under an implementation-defined relaxation, provisional changes may be visible, at some point or to some degree, to other GQL-agents executing concurrent transactions. After a successful COMMIT, the transaction’s changes are eligible to be perceived by all subsequent transactions.

19.2 Serializability and Isolation

Serializability. The GQL core models only serializable transactional behavior. Thus, whenever transactions are described concurrently in this core model, there exists a total order $\prec$ of the committed transactions such that the observable outcome (final state and results of each transaction) is equivalent to executing those transactions one-by-one in order $\prec$. An implementation-defined relaxation need not satisfy this criterion unless it is specified as a serializable extension. For $\mathrm{Tx}=⟨u,\mathrm{iso},⟨P_1,\dots <!--\; FUNCTION\; APPLICATION\; -->,P_m⟩,\mathrm{SP}⟩$, write $\mathrm{\Delta }(\mathrm{Tx})$ for the cumulative delta obtained by composing $\mathrm{\Delta }(P_1),\dots <!--\; FUNCTION\; APPLICATION\; -->,\mathrm{\Delta }(P_m)$ in procedure-execution order:

Let ${\mathrm{\Omega }}_{\mathrm{init}}$ be the initial shared store state and ${\mathrm{\Omega }}_{\mathrm{final}}$ the resulting final shared store state. Formally, if the committed transactions are ${\mathrm{Tx}}_1,\dots <!--\; FUNCTION\; APPLICATION\; -->,{\mathrm{Tx}}_n$ and $\rho$ is a permutation witnessing serializability, then

and each ${\mathrm{Tx}}_{\rho (i)}$ observes effects of ${\mathrm{Tx}}_{\rho (j)}$ for all $j<i$ and none of $j>i$.

Snapshots. For an implementation-defined isolation extension, let ${\mathrm{\Omega }}_i^{\mathrm{base}}$ denote the base store state made visible to statement $S_i$ by that extension. It may, for example, be selected at transaction start or at a statement boundary. The GQL core does not standardize such snapshot-selection rules. In the serializable core model, ${\mathrm{\Omega }}_i^{\mathrm{base}}$ is the committed state established by the transactions preceding this transaction in the witnessing serial order.

Isolation levels (axiomatic sketch). Isolation levels other than SERIALIZABLE, their interactions, their granularity, and the means of selecting them are implementation-defined. The following are examples of policies an extension might choose, not GQL-defined levels:

• $\mathrm{READ}\mathrm{COMMITTED}$ (RC): each statement reads from the latest committed state at its start; writes are private until commit.
• $\mathrm{REPEATABLE}\mathrm{READ}$ (RR): the base state is fixed for the transaction.
• $\mathrm{SNAPSHOT}\mathrm{ISOLATION}$ (SI): commit succeeds iff no write-write conflict on overlapping entities/fields (first-committer-wins); otherwise a rollback in class 40xxx.
• $\mathrm{SERIALIZABLE}$ (SER): there exists a serial order of concurrent transactions producing an equivalent outcome.

Statement execution under isolation. Let ${\mathrm{\Delta }}_i$ be the delta produced by a successfully completed statement $S_i$, and let

Both the read part and the computation of the write part of $S_i$ use ${\mathrm{\Omega }}_i^{\mathrm{vis}}$. If $S_i$ completes successfully, its delta is added to the transaction-local cumulative delta, so the next statement observes it. This explicitly provides the standard’s statement sequencing rule that the effects of a successfully completed statement are visible to a successor statement in the same transaction. If $S_i$ signals an exception, evaluation of the enclosing request stops with that GQLSTATUS and ${\mathrm{\Delta }}_i$ is not added.

19.3 Errors and Aborts

Abort outcomes. In the abstract model, execution may terminate with a successful $\mathrm{RolledBack}(\cdot )$ or with $\mathrm{Aborted}(\kappa )$, in addition to $\mathrm{Committed}(\cdot )$. The first is an explicitly requested successful rollback; the second records a failed outcome and rollback attempt. In either case, a successful rollback leaves no lasting transaction effect, while $\mathrm{Aborted}(\kappa )$ also raises exception condition $\kappa$ to the agent.

Sources of termination without commit. A transaction can terminate without committing in any of the following situations: (i) an explicit ROLLBACK command, unless disallowed by an externally controlled encompassing transaction, successfully cancels its changes; (ii) the execution of a procedure has a failed outcome, which causes the GQL-implementation to attempt to roll back the current transaction; (iii) a COMMIT encounters an error other than invalid termination 2D000 that prevents commitment, in which case its changes are canceled and 40000 is raised with an implementation-defined subclass; or (iv) the transaction becomes blocked, cannot complete without semantic inconsistency, or loses resources required to continue, in which case it is implementation-dependent whether rollback is forced.

Rollback (abort) effect. If rollback of the currently active transaction succeeds, then all changes to GQL-data and/or the GQL-catalog performed by that transaction are canceled; the transaction is terminated and the current transaction is set to “not set”. No provisional effect remains in the store. Under a less restrictive, implementation-defined isolation extension, this does not retroactively erase an observation that the extension may already have allowed another agent to make.

Error effect and diagnostics. If a statement signals an exception condition, the GQL-request is unsuccessful, the applicable General Rules stop, and the request has no effect on GQL-data or the GQL-catalog. If the exception propagates to a failed procedure outcome, the implementation attempts to roll back the current transaction. This does not replace every original statement condition with class 40: a transaction-rollback condition has precedence only when such a condition is actually raised (for example, 40000 when commitment is prevented). The presentation of diagnostics and the reporting of additional conditions are implementation-defined; logging and retry strategies are not specified.