Name: Barnabas Oretan

Matric no: PG/24/0402

Course Code: COSC 761

Date: 04/11/2024

Topic: Acid, Rollback,

Commit, Abort
ACID Transactions in Databases

ACID (Atomicity, Consistency, Isolation, and Durability) is a set of properties that guarantee reliable
processing of database transactions. When a database transaction adheres to these principles, it ensures
that the database remains accurate, even in the face of errors or power failures. ACID properties are
critical, particularly in financial systems and healthcare databases, where data accuracy and consistency
are paramount.

1. Atomicity

Atomicity ensures that a transaction is all-or-nothing. This means that a transaction must either fully
complete or have no effect on the database. In a financial context, consider a bank transfer where
Customer A transfers $500 to Customer B. The transaction involves two steps: deducting $500 from
Customer A’s account and adding $500 to Customer B’s account. Atomicity guarantees that both
operations either succeed together or fail together. If, for instance, the transaction fails midway (say, after
deducting $500 from Customer A but before adding it to Customer B), the database should roll back to
the initial state, ensuring no partial updates remain.

In a healthcare scenario, atomicity is equally vital. Consider an update to a patient’s record where new
medication data is added along with allergy information. If the transaction fails while updating, atomicity
ensures that either both changes occur or none at all, avoiding an inconsistent state where only partial
updates are recorded.

2. Consistency

Consistency ensures that a transaction takes the database from one valid state to another, maintaining data
integrity by enforcing all predefined rules. In financial transactions, this includes constraints like account
balance cannot be negative. For instance, if Customer A has only $200 but tries to transfer $500 to
Customer B, the transaction would violate the balance constraint, thereby failing to maintain consistency.
This principle prevents the bank’s system from allowing transactions that break business rules, protecting
against data corruption.

In healthcare, consistency can ensure that a doctor’s prescription aligns with the patient’s allergy profile
or that the dosage fits medical standards. Suppose a transaction attempts to store a medication dosage
outside the acceptable range; the database will enforce consistency rules, preventing the transaction and
preserving data accuracy.

3. Isolation

Isolation ensures that concurrently running transactions do not affect each other. This is crucial in systems
where multiple users interact with the database simultaneously. In a financial example, if two transactions
try to access the same account balance to transfer money simultaneously, isolation prevents them from
interfering. Using isolation levels such as “serializable,” the database ensures that one transaction
completes fully before another begins, avoiding potential issues like lost updates or dirty reads.
In healthcare, isolation is essential to protect patient confidentiality and ensure that updates happen
without errors. For example, if two doctors try to update the same patient’s record simultaneously,
isolation prevents data overwrites and ensures each change is accurately applied. Without isolation, one
doctor’s changes could inadvertently overwrite the other’s, leading to incorrect medical records and
potential patient harm.

Transaction Scenario Importance of Isolation

Type

Financial Multiple transfers on an Prevents concurrent updates that could cause overdrafts
Transfer account or miscalculations

Patient Record Doctors updating the Ensures each update is applied without data loss
Update same record

4. Durability

Durability ensures that once a transaction is completed, the changes persist even in the event of system
crashes or power failures. In financial transactions, durability guarantees that a completed bank transfer
remains in the database. After a successful $500 transfer from Customer A to Customer B, durability
ensures that this update is not lost, even if there’s a sudden system shutdown. This reliability is crucial for
maintaining user trust in banking systems.

In healthcare, durability is equally critical. Once a doctor’s update to a patient’s record is saved, durability
guarantees that the change will persist, even if the system crashes immediately afterward. For instance, if
a doctor prescribes a life-saving medication, durability ensures this information is reliably stored and
retrievable when needed.

Practical Example: ACID in Action

Scenario: Suppose a hospital’s billing department runs a transaction to update a patient’s financial and
medical records after a surgery. This includes deducting the patient’s account for the surgery fee and
updating the patient’s medical history with the surgery details.

1. Atomicity: Both updates (financial deduction and medical record update) are processed as a
single transaction. If one fails (e.g., due to insufficient balance), both are rolled back, preventing
partial updates.
2. Consistency: The system checks predefined rules (e.g., balance constraints or valid surgery
codes) to ensure data integrity.
3. Isolation: If another transaction (like a new lab test billing) is executed concurrently on the same
patient’s account, isolation ensures both are handled without interference, avoiding issues like
incorrect balance or record inconsistencies.
4. Durability: Once the transaction is complete, both updates are permanently recorded, ensuring
that the hospital’s database reflects the latest accurate information, even after system restarts.
Consequences of Non-ACID Compliance

Without ACID properties, the following risks arise:

● Data Corruption: Partial updates (atomicity failure) may lead to inconsistent data, like
incomplete financial transactions or missing medical record updates.
● Rule Violations: Without consistency, databases may hold invalid states, allowing transactions
that violate business or medical rules, potentially leading to financial losses or medical errors.
● Concurrency Issues: Without isolation, multiple transactions may interfere, leading to issues
such as incorrect balances in financial systems or incorrect patient records in healthcare
databases.
● Data Loss: Lack of durability increases the risk of data loss in system failures, leading to
potential financial discrepancies or lost patient medical history.

Conclusion

ACID properties are fundamental to transactional integrity, ensuring that database operations are
processed reliably. In critical applications like financial systems and healthcare databases, ACID
compliance maintains trust, data accuracy, and system reliability, making it indispensable for high-stakes
transactional environments.

Abort, Commit, and Rollback in Database Transactions

In transactional databases, the terms abort, commit, and rollback represent critical control mechanisms
that manage how transactions interact with data to ensure reliability, especially when errors or conflicts
arise. Here’s a detailed, technical breakdown of these concepts, emphasizing their application in practical
industries, along with their importance, benefits, and drawbacks.

1. Abort

Definition: An abort is an explicit cancellation of a transaction before it completes. This is often triggered
when a system detects a violation of ACID properties, such as consistency or isolation. An abort typically
occurs if a transaction encounters an error, rule violation, or if it’s forced by a system or user decision.

Technical Elements:

● Transaction Logs: When a transaction is aborted, transaction logs are updated, capturing details
for auditing and analysis. Logs often record pre-transaction states, allowing the database to revert
to the previous state.
● Locks and Resources: Upon abort, any locks held by the transaction on the database resources
are released, making them available for other transactions.
● Error Handling Mechanism: Errors in data constraints (such as foreign key violations in
relational databases) or system-level conflicts trigger an abort, preventing the transaction from
proceeding to an inconsistent state.
Practical Industry Examples:

● Banking: In a funds transfer scenario, an abort may occur if a transaction tries to transfer more
money than the account balance. Here, the database detects the constraint violation and aborts the
transaction, leaving the account unchanged.
● Healthcare: When updating a patient’s record, if a doctor tries to prescribe a medication that
conflicts with an allergy constraint, the system may abort the update, preventing potentially
harmful data entry.

2. Commit

Definition: Commit finalizes a transaction, making all changes permanent in the database. Once
committed, the transaction cannot be undone, even in case of system failure, due to the durability property
of ACID.

Technical Elements:

● Transaction Log Finalization: The transaction log is updated to record the completion of the
transaction, ensuring that changes can be recovered if the database crashes.
● Write-Ahead Logging (WAL): Databases typically use WAL, where changes are first written to
a log file before committing to ensure data integrity.
● Concurrency Control: Locks held during the transaction are only released after the commit,
enabling other transactions to access modified data in its final, stable state.

Practical Industry Examples:

● E-commerce: When a customer completes a purchase, the transaction commits once the payment
clears. This commits updates to both inventory and customer order history, ensuring accurate
stock tracking and sales records.
● Retail: In point-of-sale (POS) systems, the commit step finalizes the sale by updating stock
levels, customer data, and financial records, making the transaction permanent and trackable for
future audits.

3. Rollback

Definition: A rollback reverts the database to its previous state before the transaction began, undoing all
changes. A rollback typically follows an abort or a detected error within the transaction.

Technical Elements:

● Undo Logs: During a transaction, undo logs keep track of the data state before changes are made.
In a rollback, the database system references these logs to restore pre-transaction values.
● Savepoints: Complex transactions can define savepoints, which allow partial rollbacks to specific
points within a transaction. This means that only part of the transaction is undone, while the rest
proceeds.
 ● Resource Deallocation: Rollbacks release resources and locks held by the transaction, making
them available for other operations.

Practical Industry Examples:

● Financial Services: If a transaction processing system detects an error after half of the operations
are performed, a rollback can cancel all intermediate steps, ensuring that accounts and balances
remain unchanged.
● Healthcare: In hospital billing systems, if an error occurs while processing a complex billing
transaction, a rollback undoes any partial charges applied to patient records, preventing inaccurate
billing.

Importance of Abort, Commit, and Rollback

These three mechanisms are essential for transaction integrity, especially in high-stakes industries like
finance, healthcare, and e-commerce.

● Data Integrity: Abort, commit, and rollback help maintain consistent, accurate data across
systems.
● Error Management: By allowing transactions to abort or rollback, databases can handle
unexpected issues gracefully, avoiding corrupted or incomplete records.
● Auditability: Through logging and commit/rollback actions, databases provide a clear, auditable
history of operations, which is crucial for compliance and security.

Merits and Demerits of Abort, Commit, and Rollback

Merits

1. Enhanced Data Consistency: Transactions remain consistent and accurate, upholding ACID
principles.
2. Fault Tolerance: Systems can handle failures without compromising data, as rollback and abort
mechanisms ensure the system reverts to a known, stable state.
3. Scalability for Concurrent Users: Commit and rollback processes effectively manage multiple
users and transactions, supporting scalability.

Demerits

1. Resource Overhead: Frequent aborts or rollbacks increase resource usage due to the need for
lock management, logging, and undo mechanisms.
2. Transaction Latency: Rolling back large transactions or waiting for commit operations can
increase transaction latency, especially in systems with high data volumes.
3. Complexity in Concurrency Control: Managing concurrent access through commit and rollback
can lead to complex scenarios, like deadlock, which can be challenging to resolve and optimize.

Summary Table
 Mechanism Role Benefits Drawbacks

Abort Cancels transactions on Maintains data Can increase system

error integrity, prevents rule load due to frequent
violations aborts

Commit Finalizes transaction Ensures durable, Increases latency,

changes reliable changes especially under heavy
load

Commit Finalizes transaction Ensures durable, Increases latency,

changes reliable changes especially under heavy
load

Rollback Reverts to previous Undoes partial updates, Requires extra

state protects against errors storage/logging, can
slow system

In summary, abort, commit, and rollback are vital mechanisms in transaction processing, ensuring data
integrity and robustness in complex and high-transaction environments. They empower databases to
handle both expected and unexpected challenges while maintaining consistency and reliability, though
they come with resource demands that require careful system design and management.

References

A. Kumar, "Transaction Processing and the ACID Properties," Journal of Database Management, vol. 32,
no. 4, pp. 15-25, 2022.
J. Gray and A. Reuter, Transaction Processing: Concepts and Techniques, San Francisco, CA, USA:
Morgan Kaufmann, 1993.
H. Garcia-Molina, J. D. Ullman, and J. Widom, Database Systems: The Complete Book, 2nd ed., Upper
Saddle River, NJ, USA: Prentice Hall, 2009.
P. Bernstein and E. Newcomer, Principles of Transaction Processing for the Systems Professional, San
Francisco, CA, USA: Morgan Kaufmann, 1997.
M. Ozsu and P. Valduriez, Principles of Distributed Database Systems, 3rd ed., New York, NY, USA:
Springer, 2011.
S. K. Das, R. Mandal, and D. Sen, "ACID vs. BASE in Distributed Databases: A Comparative Analysis,"
in Proceedings of the 2021 International Conference on Data and Software Engineering (ICDSE),
Kolkata, India, 2021, pp. 72-77.
Y. Wang, R. Chirkova, and J. Yang, "A Study on Database Consistency in E-Commerce Systems," IEEE
Transactions on Knowledge and Data Engineering, vol. 31, no. 4, pp. 766-780, Apr. 2019.
G. Weikum and G. Vossen, Transactional Information Systems: Theory, Algorithms, and the Practice of
Concurrency Control and Recovery, San Francisco, CA, USA: Morgan Kaufmann, 2001.
T. Härder and A. Reuter, "Principles of Transaction-Oriented Database Recovery," ACM Computing
Surveys, vol. 15, no. 4, pp. 287-317, Dec. 1983.
M. Stonebraker, "The Case for Partial Rollback in Transaction Systems," in Proceedings of the ACM
SIGMOD International Conference on Management of Data, New York, NY, USA, 1988, pp. 141-145.