Museum

Home

Lab Overview

Retrotechnology Articles

⇒ Online Manual

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

CONCURRENCY Transaction changes

RDB/VMS Relational Database Operator NEW_FEATURES_V4.2 — VMS RDB_4.2

 The RDO 4.2 new features and technical changes include:

Additional information available:

CONCURRENCY Transaction changes

CONCURRENCY Transaction changes

 The broadening of isolation level support in Rdb/VMS V4.2 changes how
 Rdb/VMS treats RDO, RDBPRE, and RDML applications that use
 CONCURRENCY transactions against Rdb/VMS V4.2 databases.  No longer
 do such applications ignore the CONCURRENCY setting by running their
 transactions at the default CONSISTENCY setting.  Instead, they run
 the transactions at the CONCURRENCY setting specified.  This changed
 transaction behavior can affect your existing RDO, RDBPRE, and RDML
 applications.

 Because Rdb/VMS V4.2 expands the CONCURRENCY setting in the
 START_TRANSACTION statement of RDO, your DBA should check those RDO,
 RDBPRE, and RDML applications that specify the CONCURRENCY keyword in
 START_TRANSACTION statements to ensure that the applications return
 expected results at the reduced consistency level defined by the
 CONCURRENCY setting.

 Your RDO, RDBPRE, and RDML applications that explicitly specify
 CONCURRENCY in START_TRANSACTION statements will now operate in
 Rdb/VMS V4.2 at the equivalent (SQL) ISOLATION LEVEL READ COMMITTED
 (formerly called CONSISTENCY LEVEL 2) when attached to either
 non-Rdb/VMS databases (such as VIDA or Rdb/ELN) or Rdb/VMS V4.2
 databases.  Those RDO, RDBPRE, and RDML applications that do not
 explicitly specify a consistency level or explicitly specify
 CONSISTENCY (default) will not change transaction behavior.

 In pre-Rdb/VMS V4.2 releases, Rdb/VMS ran application transactions at
 the CONCURRENCY setting against non-Rdb/VMS databases only and
 ignored the CONCURRENCY setting when attached to Rdb/VMS databases.
 Instead of running these latter applications at CONSISTENCY LEVEL 2
 (CONCURRENCY), as you might expect, Rdb/VMS ran them at the default
 CONSISTENCY LEVEL 3.

 For Rdb/VMS V4.2, however, RDO, RDBPRE, and RDML applications that
 use the CONCURRENCY (CONSISTENCY LEVEL 2) setting in transactions
 attached to Rdb/VMS V4.2 databases will no longer automatically
 revert to CONSISTENCY LEVEL 3 as was true in previous releases.
 Instead, they will run at the specified CONCURRENCY (CONSISTENCY
 LEVEL 2) setting.

 Refer to the table entitled "Differences in Relational Terminology"
 in the VAX Rdb/VMS New and Changed Features manual for the
 relationship between SQL isolation level terminology and its
 equivalent RDO, RDBPRE, and RDML terminology.  The VAX Rdb/VMS New
 and Changed Features manual also describes the new SQL support and
 terminology provided by Rdb/VMS V4.2.

 You can use the Rdb/VMS RDMS$DEBUG_FLAGS logical "T" option to
 determine the consistency level at which your executable images are
 running.  The "T" option displays application transaction
 characteristics and will display TPB$K_DEGREE2 for those applications
 that use the CONCURRENCY option.  The VAX Rdb/VMS Guide to Database
 Performance and Tuning for Rdb/VMS V4.1 describes how to use the
 RDMS$DEBUG_FLAGS logical name.

 Because some 4GL's also use CONCURRENCY, you should contact your 4GL
 vendor about possible changes in transaction behavior; however,
 Digital expects that in most cases the CONCURRENCY option reflects
 how your DBA wants transactions to run and also that your DBA
 understands that the reduced isolation level should not be
 detrimental to applications.

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026