6 Transactions and Concurrency Basics Online Quiz Questions

Consistency

Atomicity

Isolation

Durability

Durability guarantees that every possible business rule is automatically enforced.

Consistency preserves defined rules, though some rules may need application logic.

Isolation prevents all concurrent transactions from running at the same time.

Atomicity checks that every transaction updates at least one row.

The transaction's changes are hidden from every other transaction.

The transaction automatically retries if any operation fails.

The committed changes are recorded to survive a system failure, subject to the database's guarantees and configuration.

The transaction preserves only rules enforced by application code.

It governs which concurrent changes a transaction can see.

It guarantees that every transaction is committed immediately.

It ensures that application-level business rules are always enforced.

It lets a transaction undo only work performed before a savepoint.

COMMIT cancels uncommitted changes; ROLLBACK makes them permanent.

Both commands keep the changes, but only ROLLBACK makes them visible.

COMMIT keeps the changes; ROLLBACK cancels uncommitted changes.

Both commands cancel all changes made by earlier transactions.

All statements issued by a client are automatically grouped into one transaction.

Each standalone statement is treated as its own transaction and committed if it succeeds.

A statement is committed only if the application explicitly issues ROLLBACK.

Autocommit prevents transactions from using more than one statement.

Issue ROLLBACK after each update so both changes are committed together.

Rely on autocommit, because it groups consecutive statements into one transaction.

Use a savepoint without starting a transaction block.

Start a transaction block before the related updates and commit only after both succeed.

Check that the expected account rows were updated and enforce rules such as sufficient funds.

Assume the updates succeeded because they appear between BEGIN and COMMIT.

Use a stronger isolation level, which automatically checks every business rule.

Replace COMMIT with ROLLBACK after both updates.

It commits the entire transaction and removes all earlier work.

It undoes work after the savepoint while keeping earlier work in the transaction.

It makes all work after the savepoint permanent immediately.

It starts a separate transaction that cannot be rolled back.

It can reduce concurrency or cause a transaction to be rejected and require a retry.

It always increases concurrency and prevents transaction failures.

It ensures all application-level business rules are enforced by the database.

It makes every database system implement named isolation levels identically.

PostgreSQL treats it as SERIALIZABLE.

PostgreSQL treats it as REPEATABLE READ.

PostgreSQL treats it as READ COMMITTED.

PostgreSQL rejects it in every configuration.

The transaction is silently committed with all conflicting changes removed.

The database converts the transaction to READ COMMITTED and never reports a failure.

The database retries the transaction automatically in every case.

The application may receive a serialization failure and should be prepared to retry.

A named isolation level always provides precisely the same guarantees in every database.

The exact guarantees and implementation of a named level can vary by database system.

Isolation levels affect only transaction durability, not concurrent visibility.

Every database treats READ UNCOMMITTED as allowing uncommitted changes to be seen.

Issue COMMIT to keep the pending changes.

Issue ROLLBACK to cancel the uncommitted changes.

Issue SAVEPOINT to make the changes permanent.

Issue BEGIN to cancel the transaction.

A check constraint that prohibits negative balances.

A commit command issued after every update.

A higher isolation level for every transaction.

A savepoint created before each update.

BEGIN

COMMIT

ROLLBACK

SAVEPOINT

BEGIN

ROLLBACK

SAVEPOINT

COMMIT

COMMIT

ROLLBACK

SAVEPOINT

BEGIN

COMMIT

BEGIN

SAVEPOINT

ROLLBACK

Each standalone statement is committed as its own transaction.

Committed changes are guaranteed to survive every possible system failure.

All business rules are enforced whether or not they are defined.

Concurrent work behaves more like transactions ran one at a time.

REPEATABLE WRITE

REPEATABLE READ

RETRYABLE READ

READ AGAIN

It treats READ UNCOMMITTED as READ COMMITTED.

It treats READ UNCOMMITTED as SERIALIZABLE.

It treats READ UNCOMMITTED as REPEATABLE READ.

It rejects READ UNCOMMITTED as an invalid level name.

It silently commits every conflicting transaction.

It guarantees that a transaction can never be rejected.

It can report a serialization failure that the application should be prepared to retry.

It automatically retries every failed transaction without application handling.

Validate important conditions before committing.

Assume every operation succeeded without checking its result.

Keep the transaction open as long as possible after its work is done.

Use a savepoint to make uncommitted changes permanent.

Keep transactions open until all unrelated application tasks are finished.

Keep transactions focused and reasonably short, validate important conditions before committing, and handle errors appropriately.

Avoid checking important conditions until after commit.

Retry every transaction indefinitely without handling errors.

Keep the debit because it succeeded, then retry only the credit.

Roll back the transaction so neither update takes effect.

Commit the debit and record the missing credit as a separate transaction.

Leave the debit in place because atomicity applies only to reads.

Assume each UPDATE changed one row because it ran without an error.

Use COMMIT to verify that both account identifiers exist.

Rely on autocommit to combine the two updates into one transaction.

Check that the expected account rows were updated.

Keep transactions open until the application shuts down.

Put unrelated database work into one long transaction.

Keep transactions focused and reasonably short.

Avoid handling transaction errors after they occur.

Assume the database checks sufficient funds even if no such rule is defined.

Enforce a business rule such as requiring sufficient funds.

Use durability guarantees to ensure the account has enough money.

Create a savepoint instead of checking the account balance.

ROLLBACK

COMMIT

BEGIN

SAVEPOINT