Hubbry Logo
Database transactionDatabase transactionMain
Open search
Database transaction
Community hub
Database transaction
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Database transaction
Database transaction
Database transaction
View on Wikipedia
from Wikipedia

A database transaction symbolizes a unit of work, performed within a database management system (or similar system) against a database, that is treated in a coherent and reliable way independent of other transactions. A transaction generally represents any change in a database. Transactions in a database environment have two main purposes:

  1. To provide reliable units of work that allow correct recovery from failures and keep a database consistent even in cases of system failure. For example: when execution prematurely and unexpectedly stops (completely or partially) in which case many operations upon a database remain uncompleted, with unclear status.
  2. To provide isolation between programs accessing a database concurrently. If this isolation is not provided, the programs' outcomes are possibly erroneous.

In a database management system, a transaction is a single unit of logic or work, sometimes made up of multiple operations. Any logical calculation done in a consistent mode in a database is known as a transaction. One example is a transfer from one bank account to another: the complete transaction requires subtracting the amount to be transferred from one account and adding that same amount to the other.

A database transaction, by definition, must be atomic (it must either be complete in its entirety or have no effect whatsoever), consistent (it must conform to existing constraints in the database), isolated (it must not affect other transactions) and durable (it must get written to persistent storage).[1] Database practitioners often refer to these properties of database transactions using the acronym ACID.

Purpose

[edit]

Databases and other data stores which treat the integrity of data as paramount often include the ability to handle transactions to maintain the integrity of data. A single transaction consists of one or more independent units of work, each reading and/or writing information to a database or other data store. When this happens it is often important to ensure that all such processing leaves the database or data store in a consistent state.

Examples from double-entry accounting systems often illustrate the concept of transactions. In double-entry accounting every debit requires the recording of an associated credit. If one writes a check for $100 to buy groceries, a transactional double-entry accounting system must record the following two entries to cover the single transaction:

  1. Debit $100 to Groceries Expense Account
  2. Credit $100 to Checking Account

A transactional system would make both entries pass or both entries would fail. By treating the recording of multiple entries as an atomic transactional unit of work the system maintains the integrity of the data recorded. In other words, nobody ends up with a situation in which a debit is recorded but no associated credit is recorded, or vice versa.

Transactional databases

[edit]

A transactional database is a DBMS that provides the ACID properties for a bracketed set of database operations (begin-commit). Transactions ensure that the database is always in a consistent state, even in the event of concurrent updates and failures.[2] All the write operations within a transaction have an all-or-nothing effect, that is, either the transaction succeeds and all writes take effect, or otherwise, the database is brought to a state that does not include any of the writes of the transaction. Transactions also ensure that the effect of concurrent transactions satisfies certain guarantees, known as isolation level. The highest isolation level is serializability, which guarantees that the effect of concurrent transactions is equivalent to their serial (i.e. sequential) execution.

Most modern relational database management systems support transactions. NoSQL databases prioritize scalability along with supporting transactions in order to guarantee data consistency in the event of concurrent updates and accesses.

In a database system, a transaction might consist of one or more data-manipulation statements and queries, each reading and/or writing information in the database. Users of database systems consider consistency and integrity of data as highly important. A simple transaction is usually issued to the database system in a language like SQL wrapped in a transaction, using a pattern similar to the following:

  1. Begin the transaction.
  2. Execute a set of data manipulations and/or queries.
  3. If no error occurs, then commit the transaction.
  4. If an error occurs, then roll back the transaction.

A transaction commit operation persists all the results of data manipulations within the scope of the transaction to the database. A transaction rollback operation does not persist the partial results of data manipulations within the scope of the transaction to the database. In no case can a partial transaction be committed to the database since that would leave the database in an inconsistent state.

Internally, multi-user databases store and process transactions, often by using a transaction ID or XID.

There are multiple varying ways for transactions to be implemented other than the simple way documented above. Nested transactions, for example, are transactions which contain statements within them that start new transactions (i.e. sub-transactions). Multi-level transactions are a variant of nested transactions where the sub-transactions take place at different levels of a layered system architecture (e.g., with one operation at the database-engine level, one operation at the operating-system level).[3] Another type of transaction is the compensating transaction.

In SQL

[edit]

Transactions are available in most SQL database implementations, though with varying levels of robustness. For example, MySQL began supporting transactions from early version 3.23, but the InnoDB storage engine was not default before version 5.5. The earlier available storage engine, MyISAM does not support transactions.

A transaction is typically started using the command BEGIN (although the SQL standard specifies START TRANSACTION). When the system processes a COMMIT statement, the transaction ends with successful completion. A ROLLBACK statement can also end the transaction, undoing any work performed since BEGIN. If autocommit was disabled with the start of a transaction, autocommit will also be re-enabled with the end of the transaction.

One can set the isolation level for individual transactional operations as well as globally. At the highest level (READ COMMITTED), the result of any operation performed after a transaction has started will remain invisible to other database users until the transaction has ended. At the lowest level (READ UNCOMMITTED), which may occasionally be used to ensure high concurrency, such changes will be immediately visible.

Object databases

[edit]

Relational databases are traditionally composed of tables with fixed-size fields and records. Object databases comprise variable-sized blobs, possibly serializable or incorporating a mime-type. The fundamental similarities between Relational and Object databases are the start and the commit or rollback.

After starting a transaction, database records or objects are locked, either read-only or read-write. Reads and writes can then occur. Once the transaction is fully defined, changes are committed or rolled back atomically, such that at the end of the transaction there is no inconsistency.

Distributed transactions

[edit]

Database systems implement distributed transactions[4] as transactions accessing data over multiple nodes. A distributed transaction enforces the ACID properties over multiple nodes, and might include systems such as databases, storage managers, file systems, messaging systems, and other data managers. In a distributed transaction there is typically an entity coordinating all the process to ensure that all parts of the transaction are applied to all relevant systems. Moreover, the integration of Storage as a Service (StaaS) within these environments is crucial, as it offers a virtually infinite pool of storage resources, accommodating a range of cloud-based data store classes with varying availability, scalability, and ACID properties. This integration is essential for achieving higher availability, lower response time, and cost efficiency in data-intensive applications deployed across cloud-based data stores.[5]

Transactional filesystems

[edit]

The Namesys Reiser4 filesystem for Linux[6] supports transactions, and as of Microsoft Windows Vista, the Microsoft NTFS filesystem[7] supports distributed transactions across networks. There is occurring research into more data coherent filesystems, such as the Warp Transactional Filesystem (WTF).[8]

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Database transaction

View on Grokipedia
from Grokipedia
A database transaction is a logical in a database that encompasses a sequence of read and write operations, executed as an indivisible whole to ensure and consistency across concurrent user activities. This concept, fundamental to relational and many non-relational databases, originated in the as an extension of ideas to support multi-user environments, allowing multiple transactions to proceed simultaneously without interference. Transactions are typically delimited by begin and commit (or abort) commands, treating the enclosed operations as a single atomic action that either fully succeeds or is entirely rolled back in case of failure. The reliability of database transactions is defined by the properties—Atomicity, Consistency, Isolation, and Durability—which collectively guarantee valid data states despite errors, concurrency, or system crashes. Atomicity ensures that a transaction is treated as a single, indivisible unit: all operations complete successfully, or none take effect, preventing partial updates that could corrupt data. Consistency requires that a transaction brings the database from one valid state to another, preserving all defined integrity constraints such as keys, triggers, and business rules. Isolation provides the illusion that transactions execute serially, even when running concurrently, by managing locks and to avoid interference like dirty reads or lost updates. Durability mandates that once a transaction commits, its effects are permanently stored and survive subsequent failures, often achieved through and checkpointing mechanisms. These properties, first formalized as the acronym in by Theo Härder and Andreas Reuter building on earlier work by Jim Gray, enable robust in applications ranging from banking systems to platforms, where data accuracy and availability are paramount. Transaction management involves techniques like two-phase commit for distributed systems and recovery protocols to handle failures, ensuring scalability in modern cloud-based databases while adhering to ACID guarantees.

Fundamentals

Definition and Purpose

A database transaction is defined as a sequence of one or more operations, such as reads and writes, performed on a database that is treated as a single logical unit of work. This unit ensures that either all operations complete successfully, in which case the changes are permanently applied, or none are applied if any part fails, thereby maintaining the database in a consistent state. The term "logical unit" underscores that the transaction represents an indivisible block of work from the perspective of the application, abstracting away the underlying physical storage and access mechanisms. The primary purpose of database transactions is to safeguard data reliability in the face of system failures and concurrent access by multiple users. By enabling recovery mechanisms, transactions prevent partial updates that could leave the database in an inconsistent or corrupted state, such as during crashes or power losses. Additionally, they provide isolation, allowing concurrent transactions to execute without interfering with one another, which is essential for multi-user environments where simultaneous operations are common. Overall, these features ensure , meaning the database remains accurate and trustworthy even under adverse conditions. Transactions achieve these goals through properties collectively known as , which guarantee atomicity, consistency, isolation, and . The concept of database transactions emerged in the 1970s amid the development of systems, particularly with 's System R project initiated around 1974 at the IBM San Jose Research Laboratory. System R demonstrated the feasibility of with built-in transaction support, addressing the need for atomic operations to handle concurrency in production multi-user settings. This innovation was crucial as early databases transitioned from single-user to interactive, shared environments, where partial failures could otherwise compromise data reliability. An illustrative is in financial records, where every entry must balance across accounts to preserve overall integrity, much like a transaction ensures balanced database changes.

ACID Properties

The ACID properties represent a set of fundamental guarantees that ensure the reliability and correctness of database transactions in the face of errors, failures, or concurrent access. Coined as an acronym in the early , ACID stands for Atomicity, Consistency, Isolation, and , providing a framework for that has become a of management systems (RDBMS). These properties were formalized to address the challenges of maintaining in multi-user environments, where transactions must behave as indivisible units while preserving the overall state of the database. Atomicity ensures that a transaction is treated as an indivisible : either all of its operations are successfully completed, or none of them take effect, effectively rolling back any partial changes in case of failure. This property prevents databases from entering inconsistent states due to interruptions, such as system crashes or errors during execution, by leveraging mechanisms like transaction logs to uncommitted operations. For instance, in a bank transfer transaction involving debiting one account and crediting another, atomicity guarantees that both actions occur together or not at all, avoiding scenarios where funds are deducted without being added elsewhere. Consistency requires that a transaction brings the database from one valid state to another, enforcing all predefined rules, constraints, and conditions, such as primary keys, foreign keys, and check constraints. Before and after the transaction, the database must satisfy these invariants; if a transaction would violate them, it must be aborted to maintain semantic correctness. This property relies on the application logic and to define validity, ensuring that transactions do not corrupt the —for example, preventing negative balances in an inventory system if business rules prohibit it. Isolation ensures that concurrent transactions do not interfere with each other, making each transaction appear to execute in isolation even when running simultaneously. This prevents anomalies like dirty reads (reading uncommitted data), non-repeatable reads, or phantom reads, with the strongest level being serializability, where the outcome matches some sequential execution order. Isolation is achieved through protocols, allowing multiple transactions to proceed without observing each other's intermediate states, thus preserving the illusion of atomic execution. Durability guarantees that once a transaction has been committed, its changes are permanently persisted in the database, surviving any subsequent system failures, power losses, or crashes. This is typically implemented via (WAL), where changes are first recorded in a durable log before being applied to the main data structures, ensuring recovery mechanisms can reconstruct the committed state. For example, after a commit acknowledgment, the effects remain even if the system reboots, providing the reliability needed for critical applications like financial systems.

Transaction Management

Lifecycle and Operations

A database transaction follows a defined lifecycle that ensures the of modifications, consisting of initiation, execution, termination through commit or , and associated support operations. The process begins when the database management system (DBMS) explicitly or implicitly starts a transaction, assigning it a and allocating resources such as logs to track potential reversals. During execution, the transaction performs a series of read and write operations on database objects, where reads retrieve without modification and writes update records, often involving temporary locks on affected resources to maintain consistency. These operations are buffered in memory where possible, with changes logged to persistent storage for recovery purposes. Key operations during the lifecycle include resource locking to prevent conflicting concurrent access, change logging to enable recovery from failures, and the use of savepoints as intermediate markers allowing partial without aborting the entire transaction. Locking mechanisms, such as shared locks for reads and exclusive locks for writes, are acquired dynamically to serialize access to data items. Logging records all modifications in a redo log or write-ahead log (WAL), ensuring that committed changes can be replayed during system recovery to uphold . Savepoints divide the transaction into nested subunits, permitting rollback to a prior point if an error occurs in a later segment while preserving earlier work. The lifecycle concludes with either a commit, which makes all changes permanent, releases locks, and updates the database's consistent view, or a , which undoes all modifications using stored data to restore the pre-transaction state. Error handling is integral, as any failure—such as a constraint violation, deadlock, or system crash—triggers an automatic to prevent partial updates, with recovery processes using logs to reconstruct the database to a known consistent state. For illustration, consider a simple banking transfer scenario: The transaction begins by reading the balances of two accounts; if sufficient funds exist, it writes a debit to the source account and a to the destination, acquiring exclusive locks on both; upon successful verification, a commit finalizes the transfer, releasing locks and the changes; however, if funds are insufficient or an occurs, a restores the original balances, ensuring no money is lost or duplicated.

Isolation Levels and Concurrency Control

Database transactions require mechanisms to manage , ensuring that multiple transactions can execute simultaneously without compromising . Isolation levels define the degree to which one transaction must be isolated from the effects of other concurrent transactions, balancing consistency against potential anomalies such as dirty reads, non-repeatable reads, and phantom reads. The ANSI SQL standard specifies four isolation levels—READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, and SERIALIZABLE—each permitting progressively fewer anomalies to achieve stronger guarantees. At the READ UNCOMMITTED level, transactions may read uncommitted changes from other transactions, allowing dirty reads where a transaction observes temporary that may later be rolled back. READ COMMITTED prevents dirty reads by ensuring reads only access committed but permits non-repeatable reads, where a transaction may see different values for the same row upon repeated reads due to commits by other transactions. REPEATABLE READ avoids both dirty and non-repeatable reads by locking read rows, yet it allows phantom reads, where new rows satisfying a query condition appear mid-transaction due to inserts by others. SERIALIZABLE provides the strictest isolation, equivalent to executing transactions serially, preventing all three anomalies through techniques that ensure the outcome matches some serial order. The following table summarizes the ANSI SQL isolation levels and the anomalies they prevent:
Isolation LevelDirty ReadsNon-Repeatable ReadsPhantom Reads
READ UNCOMMITTEDAllowedAllowedAllowed
READ COMMITTEDPreventedAllowedAllowed
REPEATABLE READPreventedPreventedAllowed
SERIALIZABLEPreventedPreventedPrevented
Concurrency control techniques enforce these isolation levels by coordinating access to shared data. (2PL) is a pessimistic approach where transactions acquire locks in a growing phase and release them in a shrinking phase, ensuring serializability by preventing cycles in the serialization graph. Timestamp ordering assigns unique timestamps to transactions and orders operations based on these timestamps, aborting those that would violate the order to maintain serializability without locks. , in contrast, allows transactions to proceed without locks, performing reads and writes locally, then validating at commit time against concurrent changes; conflicts lead to aborts and restarts. These mechanisms involve trade-offs in performance, where stricter isolation reduces concurrency and throughput but enhances consistency. For instance, SERIALIZABLE often incurs higher lock contention and abort rates compared to READ COMMITTED, which supports greater parallelism at the cost of potential anomalies, leading to higher throughput in high-contention workloads. Lower isolation levels thus enable better in read-heavy environments by minimizing blocking. Recent developments extend these concepts for modern systems, such as snapshot isolation, which provides READ COMMITTED-like reads from a consistent snapshot while allowing concurrent writes, reducing anomalies beyond standard levels but not guaranteeing full serializability. In , serializable snapshot isolation integrates with conflict detection to achieve SERIALIZABLE guarantees efficiently, with performance close to snapshot isolation in benchmarks, with serialization failure rates under 1% in evaluated workloads. This approach suits cloud databases by leveraging versioning to boost throughput in distributed settings.

Database Implementations

In Relational Databases

In relational databases, transaction management is standardized through SQL, which provides explicit commands to initiate, commit, or abort transactions, ensuring atomicity and consistency across (DML) and (DDL) operations. The SQL standard specifies START TRANSACTION (or equivalently BEGIN TRANSACTION in some implementations) to mark the beginning of a transaction, COMMIT to permanently apply changes, and ROLLBACK to undo them, allowing partial rollbacks via SAVEPOINT for nested recovery points within a transaction. These commands integrate seamlessly with DML statements like INSERT, UPDATE, and DELETE, as well as DDL such as CREATE or ALTER TABLE, where transactions ensure that schema changes are atomic and reversible if needed. SQL also defines mechanisms to control transaction isolation, mitigating concurrency issues like dirty reads or phantom reads through the SET TRANSACTION ISOLATION LEVEL statement, which supports four standard levels: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, and SERIALIZABLE. This command must be issued at the start of a transaction to enforce the desired level, balancing consistency with performance; for instance, READ COMMITTED prevents dirty reads but allows non-repeatable reads, as per the SQL:1992 specification. Prominent relational database systems exemplify these standards with engine-specific optimizations. In MySQL, the InnoDB storage engine provides full ACID-compliant transaction support, including row-level locking and crash recovery, and has been the default engine since version 5.5 in 2010, with enhancements in version 8.0 such as improved parallel query execution; as of November 2025, the current long-term support release is 8.4, maintaining these ACID guarantees with further performance optimizations. PostgreSQL implements transactions using Multi-Version Concurrency Control (MVCC), which creates snapshots of data versions to allow concurrent reads without blocking writes, supporting all SQL isolation levels while minimizing lock contention through visibility rules based on transaction timestamps. Historically, transaction support in relational databases evolved from early SQL implementations in the 1980s, with Oracle introducing commit/rollback operations in Version 3 (1983) and read consistency in Version 4 (1984) to handle concurrent access reliably.

In NoSQL and Object Databases

NoSQL databases often prioritize scalability and availability over strict adherence to ACID properties, adopting the BASE model—standing for Basically Available, Soft state, and Eventual consistency—instead. This approach ensures the system remains operational even during network partitions or failures, with data states that may temporarily diverge but converge over time through replication and conflict resolution mechanisms. Unlike relational systems, BASE enables horizontal scaling across distributed nodes without the overhead of immediate consistency guarantees, making it suitable for high-throughput applications like social media feeds or real-time analytics. In specific NoSQL implementations, transaction support varies to balance these trade-offs. introduced multi-document transactions in version 4.0 (released in 2018), allowing atomic operations across multiple documents, collections, and even databases within a single cluster. These transactions leverage snapshot isolation to provide consistency while supporting sharded deployments since version 4.2; as of November 2025, 8.0 (2024) extends these capabilities for more efficient distributed transactions. , a , offers lightweight transactions (LWTs) using a compare-and-set mechanism based on the consensus protocol, enabling conditional updates like "insert if not exists" with linearizable consistency for specific operations. However, LWTs are optimized for low-contention scenarios and incur higher latency due to coordination across replicas. Object databases handle transactions by directly managing object graphs, preserving , encapsulation, and relationships without the need for mappings. Systems like db4o support atomic commits and rollbacks for entire object hierarchies, treating persistent objects as native extensions of in-memory ones during transactions. Similarly, Versant Object Database (now ) provides full transactions for complex object structures, including nested references and methods, often integrated via object-database mapping (ODM) tools to simplify persistence in object-oriented languages like or C++. This contrasts with relational databases, where complex data types require normalization, joins, and impedance mismatch resolution, potentially leading to performance bottlenecks in graph-like queries. A key challenge in NoSQL and object databases is balancing consistency with distribution: strong ACID guarantees can introduce coordination overhead that hinders scalability in partitioned environments, often resulting in eventual consistency trade-offs to maintain availability. Recent advances address this; for instance, Amazon DynamoDB added support for ACID transactions in 2018, enabling atomic operations across multiple items and tables while preserving its serverless, globally distributed architecture. These enhancements use optimistic concurrency control to minimize conflicts, allowing developers to handle complex workflows like inventory updates without custom reconciliation logic.

Advanced Systems

Distributed Transactions

Distributed transactions involve coordinating atomic operations across multiple independent database nodes or systems, ensuring that either all participants commit their changes or none do, thereby maintaining the properties in a networked environment. This coordination is essential in scenarios such as multi-site enterprise applications or cloud-based services where data is replicated or sharded across geographically dispersed locations. The primary challenge lies in achieving consensus despite potential failures, latency, and unreliable communication channels. The two-phase commit (2PC) protocol is a foundational mechanism for atomic commitment in distributed transactions, consisting of a prepare phase followed by a commit or abort phase. In the prepare phase, a coordinator (transaction manager) sends a prepare request to all participating resource managers (e.g., database nodes), which vote "yes" if they can commit locally or "no" otherwise, often their state durably. If all votes are affirmative, the coordinator proceeds to the commit phase, instructing all participants to commit; otherwise, it issues an abort directive. This ensures agreement but can block if the coordinator fails after the prepare phase. To address blocking issues in 2PC, particularly during coordinator failures, the three-phase commit (3PC) protocol introduces an additional pre-commit phase for enhanced . After the prepare phase (where participants confirm readiness), the coordinator sends a pre-commit message to all prepared nodes, allowing them to acknowledge without yet committing. Only then does the commit phase occur, enabling participants to recover decisions independently if the coordinator fails, as long as no more than a minority of nodes are faulty. However, 3PC operates in asynchronous networks using timeouts for failure detection and is more message-intensive, making it suitable for systems prioritizing non-blocking behavior over performance. The XA protocol, standardized by the X/Open group, provides an interface for implementing distributed transactions in SQL environments, integrating 2PC with managers like databases. It defines functions for transaction managers to enlist managers (via xa_open/xa_close), start branches (xa_start), prepare votes (xa_prepare), and commit or (xa_commit/xa_rollback), ensuring atomicity across heterogeneous systems. Despite its robustness, XA faces challenges from network partitions, where communication failures can lead to indefinite blocking or inconsistent states, requiring timeouts and recovery mechanisms to resolve orphaned transactions. In architectures, where services often manage their own databases, the pattern serves as a flexible alternative to 2PC, decomposing long-running distributed transactions into a sequence of local transactions, each with compensating actions to undo partial failures. Originating from work on process models for extended transactions, avoid global locking by orchestrating via (event-driven) or (central coordinator), trading strict for in high-availability scenarios like order processing. Blockchain-inspired distributed ledgers extend transaction coordination through consensus mechanisms like proof-of-work or proof-of-stake, enabling trustless agreement across untrusted nodes without a central coordinator, as seen in systems like where transactions are validated and appended to an immutable chain. Recent cloud-native developments, such as Google Spanner's TrueTime , leverage synchronized clocks (via GPS and atomic time) to assign bounded- timestamps to transactions, facilitating externally consistent global reads and writes without traditional 2PC overhead. TrueTime provides a time interval [earliest, latest] with uncertainty ε (typically 7ms), allowing Spanner to order commits globally while tolerating partitions through Paxos-based replication, achieving low-latency transactions at planetary scale.

Transactional File Systems

Transactional file systems apply principles of database transactions to file operations, enabling atomicity for actions such as creating, modifying, or deleting multiple files as a single unit, ensuring that either all changes succeed or none are applied. This approach leverages mechanisms like journaling or to maintain consistency and recoverability, similar to ACID durability in but tailored to storage I/O layers. The evolution of transactional file systems began in the late 1980s with research in operating systems like Sprite, where log-structured file systems (LFS) were extended to support transactions for fault-tolerant file operations. Early implementations focused on embedding transaction managers within LFS to handle atomic updates and recovery from crashes, laying the groundwork for broader adoption in production systems during the and . By the , these concepts advanced into modern designs that integrate with user-space applications and distributed environments. A prominent example is Microsoft's , which incorporates journaling through its $LogFile to record metadata changes, ensuring recoverability after failures, and extends this with Transactional NTFS (TxF) for explicit user-level transactions on file operations like renames or deletions across files. TxF uses the Kernel Transaction Manager to provide atomicity, allowing applications to group operations and roll back on errors, though it introduces some overhead due to additional . However, has indicated that TxF may be deprecated in future Windows versions, advising developers to explore alternatives like ReplaceFile API or database solutions. Reiser4, developed for as a successor to , introduces advanced transactional capabilities with support for user-defined transaction models, enabling atomic operations across file boundaries via a redo-only write-ahead log and plugin-based extensibility. Development stalled following the 2008 conviction of its creator, , for second-degree murder, which dissolved Namesys and prevented kernel integration. Despite its innovative design for handling complex, multi-file updates efficiently, Reiser4 remains an out-of-tree with limited mainstream adoption due to integration challenges with the . ZFS, originally from , with its open-source development maintained by the community and a proprietary version by , operates as a transactional using copy-on-write semantics to ensure all modifications are atomic, preventing partial updates during crashes. Its snapshots function as pseudo-transactions by capturing consistent point-in-time views of the with minimal overhead, supporting versioning and while consuming space only for diverged data. These systems offer key benefits, including robust crash recovery for interrupted file operations and built-in versioning to preserve historical states, which enhances in environments prone to failures. However, they often incur performance limitations from the overhead of or , potentially reducing throughput for high-frequency small-file workloads compared to non-transactional alternatives. In contemporary cloud storage, transactional principles have evolved into distributed implementations, such as TxFS on Linux-based systems, which builds on journaling file systems like to provide guarantees for application-level file transactions without kernel modifications. This progression supports scalable, fault-tolerant storage in cloud environments, extending early OS-level innovations to handle networked and elastic workloads.

References

  1. https://jimgray.azurewebsites.net/papers/theTransactionConcept.pdf
  2. https://arxiv.org/pdf/2310.04601
  3. https://cs-people.bu.edu/mathan/reading-groups/papers-classics/recovery.pdf
  4. https://dl.acm.org/doi/10.1145/289.291
  5. https://docs.oracle.com/en/database/oracle/oracle-database/26/cncpt/transactions.html
  6. https://www.ibm.com/docs/en/db2-for-zos/12.0.0?topic=recovery-unit-work
  7. https://www.databricks.com/glossary/acid-transactions
  8. https://codex.cs.yale.edu/avi/db-book/slides-dir/PDF-dir/ch17.pdf
  9. https://www.teradata.com/insights/data-platform/understanding-acid-compliance
  10. https://www.mongodb.com/resources/basics/databases/acid-transactions
  11. https://dl.acm.org/doi/10.1145/358769.358784
  12. https://www.ibm.com/history/relational-database
  13. https://www.cs.umd.edu/~waa/414-F11/C-TR-79-91.pdf
  14. https://www.postgresql.org/docs/current/tutorial-transactions.html
  15. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf
  16. https://www.microsoft.com/en-us/research/uploads/prod/2020/12/TO-Algs-Bernstein-GoodmanVLDB1980.pdf
  17. https://www.eecs.harvard.edu/~htk/publication/1981-tods-kung-robinson.pdf
  18. http://www.vldb.org/pvldb/vol2/vldb09-185.pdf
  19. http://pmg.csail.mit.edu/papers/icde00.pdf
  20. https://www.eecs.umich.edu/courses/cse584/static_files/papers/snapshot-psql.pdf
  21. https://arxiv.org/abs/1208.4179
  22. https://dev.mysql.com/doc/en/commit.html
  23. https://www.postgresql.org/docs/current/transaction-iso.html
  24. https://learn.microsoft.com/en-us/sql/t-sql/statements/set-transaction-isolation-level-transact-sql?view=sql-server-ver17
  25. https://blogs.oracle.com/mysql/post/still-using-myisam-it-is-time-to-switch-to-innodb
  26. https://dev.mysql.com/doc/refman/8.4/en/innodb-transaction-isolation-levels.html
  27. https://www.postgresql.org/docs/current/mvcc-intro.html
  28. https://forums.oracle.com/ords/apexds/post/a-history-of-oracle-5117
  29. https://aws.amazon.com/compare/the-difference-between-acid-and-base-database/
  30. https://neo4j.com/blog/graph-database/acid-vs-base-consistency-models-explained/
  31. https://www.mongodb.com/resources/basics/databases/nosql-explained
  32. https://www.mongodb.com/docs/manual/core/transactions/
  33. https://www.mongodb.com/company/blog/product-release-announcements/mongodb-multi-document-acid-transactions-general-availability
  34. https://www.mongodb.com/docs/manual/release-notes/8.0/
  35. https://cassandra.apache.org/doc/latest/cassandra/architecture/guarantees.html
  36. https://docs.datastax.com/en/cql-oss/3.3/cql/cql_using/useInsertLWT.html
  37. https://sceweb.uhcl.edu/liaw/Presentations/oodb/Apress.The.Definitive.Guide.to.db4o.Jun.2006.pdf
  38. https://www.actian.com/databases/nosql/
  39. https://www.geeksforgeeks.org/dbms/difference-between-rdbms-and-oodbms/
  40. https://softwareengineering.stackexchange.com/questions/194340/why-are-nosql-databases-more-scalable-than-sql
  41. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transaction-apis.html
  42. https://aws.amazon.com/blogs/aws/new-amazon-dynamodb-transactions/
  43. https://research.google.com/archive/spanner-osdi2012.pdf
  44. https://lamport.azurewebsites.net/video/consensus-on-transaction-commit.pdf
  45. https://s2.smu.edu/~mhd/8330f11/p133-gray.pdf
  46. https://www.cs.utexas.edu/~lorenzo/corsi/cs380d/papers/Ske81.pdf
  47. https://pubs.opengroup.org/onlinepubs/009680699/toc.pdf
  48. https://www.usenix.org/system/files/conference/atc18/atc18-hu.pdf
  49. https://docs.oracle.com/cd/E19253-01/819-5461/zfsover-2/
  50. https://www.seltzer.com/assets/publications/Transaction-Support-in-a-LogStructured-File-System.pdf
  51. https://learn.microsoft.com/en-us/windows/win32/fileio/transactional-ntfs-portal
  52. https://learn.microsoft.com/en-us/windows-server/storage/file-server/ntfs-overview
  53. https://learn.microsoft.com/en-us/windows/win32/fileio/deprecation-of-txf
  54. https://lwn.net/2001/1108/a/reiser4-transaction.php3
  55. https://docs.oracle.com/cd/E19253-01/819-5461/gbciq/index.html
  56. https://openzfs.org/wiki/Main_Page
  57. https://learn.microsoft.com/en-us/windows/win32/fileio/about-transactional-ntfs
Add your contribution
Related Hubs
User Avatar
No comments yet.