mo_rollback_txn_on_error

The mo_rollback_txn_on_error system variable controls what a failed statement does to an open transaction. The default 0 rolls back only the failing statement and leaves the transaction open (MySQL behavior). Setting it to 1 treats any error as fatal to the whole transaction.

The mo_rollback_txn_on_error system variable changes how MatrixOne handles an error that occurs inside an open transaction. By default, a statement error — a duplicate key, an unknown column, a type-conversion failure, a missing table — rolls back only that statement and the transaction survives, matching MySQL. When the variable is set to 1, any error discards the whole transaction, including work done before the failure.

Syntax

SET SESSION mo_rollback_txn_on_error = 0; SET SESSION mo_rollback_txn_on_error = 1;

Query the current value:

SHOW VARIABLES LIKE ‘mo_rollback_txn_on_error’; SELECT @@mo_rollback_txn_on_error;

Arguments

Property

Value

Variable Type

bool

Scope

Both

Dynamic

Yes

Default Value

0

Optional Value

0, 1

Examples

DROP DATABASE IF EXISTS rb_demo;
CREATE DATABASE rb_demo;
USE rb_demo;

CREATE TABLE t (a INT PRIMARY KEY, b VARCHAR(10));
INSERT INTO t VALUES (1, 'one');

-- default: the failing statement is rolled back, the transaction survives
BEGIN;
INSERT INTO t VALUES (20, 'twenty');
-- Expected-Success: false
INSERT INTO t VALUES (1, 'dup');
INSERT INTO t VALUES (21, 'twentyone');
COMMIT;
SELECT a FROM t ORDER BY a;

-- opted in: any error discards the whole transaction, including prior work
SET mo_rollback_txn_on_error = 1;
DELETE FROM t WHERE a <> 1;
BEGIN;
INSERT INTO t VALUES (30, 'thirty');
-- Expected-Success: false
INSERT INTO t VALUES (1, 'dup');
COMMIT;
SELECT a FROM t ORDER BY a;

DROP DATABASE rb_demo;

Constraints

  • The default 0 preserves MySQL semantics: only the failing statement is rolled back.

  • With 1, any error — a duplicate key, an unknown column, a bad type, a missing table, or a parse error — rolls back the entire transaction.

  • Only errors discard a transaction; informational and warning codes never do.

  • A global assignment leaves the current session unchanged and is inherited by sessions opened afterwards.