It is now more than 20 years since two researchers, Theo Haërder and Andreas Reuter, published a review paper describing requirements for maintaining the integrity of a database in a parallel updating environment. They distilled the requirements into four precepts defined as atomicity, consistency, isolation, and durability—abbreviated as ACID. Over the succeeding years, the ACID concept evolved as a benchmark for the implementation of transactions in database systems.
A transaction (also known as a unit of work) is described as consisting of a collection of data -transforming actions. To be “atomic,” the transaction must be implemented in such a way that it provides the “all -or -nothing illusion that either all of these operations are performed or none of them is performed.” The transaction either completes as a whole (commits) or aborts (rolls back).
Transactions are assumed to perform correct transformations of the abstract system state—that is, the database must be left in a consistent state after a transaction completes, regardless of whether it commits or rolls back. The transaction concept assumes that programmers have mechanisms available to them for declaring points of consistency and validating them. In SQL, the standards provide for triggers, referential integrity constraints, and check constraints to implement those mechanisms at the server.
While a transaction is updating shared data, the system must give each transaction the illusion that it is running in isolation; it should appear that all other transactions ran either before it began or after it committed. While data is in transition from a starting consistent state to a final consistent state, it may be inconsistent with database state, but no data may be exposed to other transactions until the changes are committed.
Next chapter explores the three levels of isolation for transactions that Firebird implements, along with the options available to respond to conflicts and prevent the work of one transaction from interfering with the work of another.
Once a transaction commits, its updates must be durable—that is, the new state of all objects made visible to other transactions by the commit will be preserved and irreversible, regardless of events such as hardware failure or software crashing
Firebird Related Interview Questions
|RDBMS Interview Questions||MySQL Interview Questions|
|Linux Interview Questions||Mac OS X Deployment Interview Questions|
|Windows Administration Interview Questions||Windows Server 2003 Interview Questions|
|SQL Interview Questions||NoSQL Interview Questions|
|Advanced C++ Interview Questions|
Introduction To Client/server Architecture
About Firebird Data Types
Date And Time Types
Blobs And Arrays
From Drawing Board To Database
Creating And Maintaining A Database
Firebird’s Sql Language
Expressions And Predicates
Querying Multiple Tables
Ordered And Aggregated Sets
Overview Of Firebird Transactions In
Programming With Transactions
Introduction To Firebird Programming
Developing Psql Modules
Error Handling And Events
Security In The Operating Environment
Configuration And Special Features
Interactive Sql Utility (isql)
Database Backup And Restore (gbak)
Housekeeping Tool (gfix)
Understanding The Lock Manager
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.