Transactions in databases

Transaction is an impact on a database that transfers it from one consistent state to another and is expressed in changing the data stored in the database.

Main properties of the transaction

Atomicity ensures that no transaction is partially committed in the system. Either all of its suboperations will be executed, or none of them will be executed.

Consistency. A transaction that reaches its normal completion and thus commits its results maintains database consistency.

Isolation. During the execution of a transaction, concurrent transactions should not affect its outcome.

Durability. Regardless of problems at the lower levels (for example, a system outage or hardware failures), changes made by a successfully completed transaction should remain saved after the system is returned to work.

Levels of transaction isolation

In order to increase the isolation of transactions and, accordingly, the reliability of working with data:

  • Read uncommitted (dirty read) - read uncommitted changes both from your own transaction and from parallel transactions. There is no guarantee that data changed by other transactions will not be changed at any time as a result of their rollback, so this reading is a potential source of errors. Lost changes are not possible, non-repeatable reads and phantoms are possible.
  • Read committed - read all changes in your transaction and committed changes in parallel transactions. Lost changes and dirty reads are not allowed, nonrepeatable reads and phantoms are possible.
  • Repeatable read (snapshot) - reading all changes in your transaction, any changes made by parallel transactions after the start of their own are not available. Lost changes, dirty and unrepeatable reads are impossible, phantoms are possible.
  • Serializable - the result of parallel execution of a serializable transaction with other transactions must be logically equivalent to the result of any sequential execution of them. Synchronization problems do not arise.

What problems can arise with concurrent access using transactions?

With parallel execution of transactions, the following problems are possible:

  • Lost update - when one data block is simultaneously changed by different transactions, one of the changes is lost;
  • "Dirty" read - reading data, added or modified by a transaction, which subsequently will not be confirmed (rolled back);
  • Non-repeatable read - after repeated reading within one transaction, the previously read data is changed;
  • Phantom reads - one transaction during its execution several times selects many records according to the same criteria. Another transaction, in the intervals between these selections, adds or deletes records, or modifies the columns of some of the records used in the selection criteria of the first transaction, and ends successfully. As a result, it turns out that the same samples in the first transaction give different sets of records.

Read also:


Comments

Post a Comment

Popular posts from this blog

Methods for reading XML in Java

Image
DOM (Document Object Model) - object - reads XML, recreating it in memory in the form of an object structure, while the XML document is represented as a set of tags - nodes. Each node can have an unlimited number of child nodes. Each child can also contain several levels of descendants or none at all. Thus, the result is a kind of tree. Pluses: Easy to program. If there are many objects in XML with cross-references to each other, it is enough to go through the document twice: first time create objects without references and fill in the name-object dictionary, the second time - restore links. If an error occurs in XML, a half-created XML structure remains in memory, which will be automatically destroyed. Suitable for both reading and writing. Minuses: Low speed. Wastes a lot of memory. SAX (Simple API for XML) - event-driven - reads an XML document, responding to emerging events (opening or closing tag, string, attribute) by calling the event handlers provided by the appl...
Read more

XML, well-formed XML and valid XML

Image
XML, the eXtensible Markup Language, is a language with a simple formal syntax, well suited for creating and manipulating documents with programs, and at the same time easy to read and create documents by humans. XML is extensible, it does not fix the markup used in documents, and the developer is free to create markup in accordance with the needs of a particular area, being limited only by the syntax rules of the language. DTD A DTD, Document Type Definition, is a predefined set of rules that defines the relationships between elements and attributes. For example, the DTD for HTML says that the DIV tag must be inside the BODY tag and can appear multiple times, TITLE - in HEAD and only once, and SCRIPT - both there and there as many times as you want. A DTD is usually described directly in the document as a formulation line starting with <!DOCTYPE ... > or in a separate file. Difference between well-formed XML and valid XML Depending on the level of compliance, the document...
Read more

ArrayList and LinkedList in Java, memory usage and speed

Image
How much extra memory is needed when calling ArrayList.add()? If there is enough space in the array to accommodate a new element, then no additional memory is required. Otherwise, a new array is created, 1.5 times larger than the existing one (this is true for JDK above 1.7, in earlier versions the size of the increase is different). How much extra memory is allocated when you call LinkedList.add()? One new instance of the nested Node class is created. How much memory to store one byte primitive in LinkedList? Each LinkedList element stores a link to the previous element, the next element, and a data link. private static class Node<E> { E item; Node<E> next; Node<E> prev; //... } For 32-bit systems, each link is 32 bits (4 bytes). The object (header) of the nested Node class itself takes 8 bytes. 4 + 4 + 4 + 8 = 20 bytes, and since the size of each object in Java is a multiple of 8, so we get 24 bytes. A byte primitive occupies 1 by...
Read more