跳至主要内容

Deep in Transaction (1)

Deep in Transaction (1)

When it comes transaction, we think of ACID property, we think of a bunch of actions which should be done in all or nothing.

Atomicity: guarantees that each transaction is treated as a single “unit”
Consistency: ensures that a transaction can only bring the database from one valid state to another
Isolation: ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially
Durability: guarantees that once a transaction has been committed, it will remain committed even in the case of a system failure

It seems all four rules of ACID are the equally property for a transaction, but it is not.

Why We Need Transaction

To make it clear, the very first goal of transactions is to ensure that all of the objects managed by a server remain in a consistent state when they are accessed by multiple transactions and in the presence of server crashes.

The core is to keep state consistent when

  • there are multiple transactions access object concurrent;
  • there are server crash/failure;

So, we need a transaction to be

  • isolated from other transaction (Isolation & Atomicity):
    • serially: one transaction at a time, in some arbitrary order
    • serially equivalent or serializable: this would have the same effect as a serial execution
  • applied on recoverable object (Durability):

    when a server process crashes unexpectedly due to a hardware fault or a software error, the changes due to all completed transactions must be available in permanent storage so that when the server is replaced by a new process, it can recover the objects to reflect the all-or-nothing effect.

We have method Isolation & Atomicity & Durability, but no Consistency, because programmers it is generally responsible to ensure that transactions leave the database consistent, i.e. we have to write right/enough unit of operations (follow is a wrong unit).

transation: transfer

accountA: withdraw 10
accountB: deposit 9

Failure Types

As an application programmer, we can understand Isolation & Atomicity very well because we also met those kinds of problems in application program, when we are working in multi-thread/process world. We need to coordinate different threads to access shared object in sequence.

But we don’t always have chance to consider Durability. In order to have this property, we first have to understand what kinds of failure/crash server may encounter:

  • Writes to permanent storage may fail, either by writing nothing or by writing a wrong value – for example, writing to the wrong block is a disaster. File storage may also decay.

  • Servers may crash occasionally. When a processor is faulty, it is made to crash so that it is prevented from sending erroneous messages and from writing wrong values to permanent storage – that is, so it cannot produce arbitrary failures. Crashes can occur at any time; in particular, they may occur during recovery.

  • There may be an arbitrary delay before a message arrives. A message may be lost, duplicated or corrupted. Both forged messages and undetected corrupt messages are regarded as disasters.

In order to solve storage failure, server failure and message failure, we can:

  • Reads from permanent storage can detect (by a checksum) when a block of data is bad; Failure to write storage will abort all transaction and shutdown server.
  • When a crashed server is replaced by a new process, its volatile memory is first set to a state in which it knows none of the values (for example, of objects) from before the crash. After that it carries out a recovery procedure (kinds of operation log) using information in permanent storage and obtained from other processes to set the values of objects including those related to the two-phase commit protocol.
  • The recipient can detect corrupted messages using a checksum & lost message is re-sent by by reliable channel (like TCP) & dup messages should be handled by different instances of server.

Ref

  • ACID
  • DISTRIBUTED SYSTEMS: Concepts and Design

Written with StackEdit.

评论

此博客中的热门博文

Spring Boot: Customize Environment

Spring Boot: Customize Environment Environment variable is a very commonly used feature in daily programming: used in init script used in startup configuration used by logging etc In Spring Boot, all environment variables are a part of properties in Spring context and managed by Environment abstraction. Because Spring Boot can handle the parse of configuration files, when we want to implement a project which uses yml file as a separate config file, we choose the Spring Boot. The following is the problems we met when we implementing the parse of yml file and it is recorded for future reader. Bind to Class Property values can be injected directly into your beans using the @Value annotation, accessed via Spring’s Environment abstraction or bound to structured objects via @ConfigurationProperties. As the document says, there exists three ways to access properties in *.properties or *.yml : @Value : access single value Environment : can access multi

Elasticsearch: Join and SubQuery

Elasticsearch: Join and SubQuery Tony was bothered by the recent change of search engine requirement: they want the functionality of SQL-like join in Elasticsearch! “They are crazy! How can they think like that. Didn’t they understand that Elasticsearch is kind-of NoSQL 1 in which every index should be independent and self-contained? In this way, every index can work independently and scale as they like without considering other indexes, so the performance can boost. Following this design principle, Elasticsearch has little related supports.” Tony thought, after listening their requirements. Leader notice tony’s unwillingness and said, “Maybe it is hard to do, but the requirement is reasonable. We need to search person by his friends, didn’t we? What’s more, the harder to implement, the more you can learn from it, right?” Tony thought leader’s word does make sense so he set out to do the related implementations Application-Side Join “The first implementation

Implement isdigit

It is seems very easy to implement c library function isdigit , but for a library code, performance is very important. So we will try to implement it and make it faster. Function So, first we make it right. int isdigit ( char c) { return c >= '0' && c <= '9' ; } Improvements One – Macro When it comes to performance for c code, macro can always be tried. #define isdigit (c) c >= '0' && c <= '9' Two – Table Upper version use two comparison and one logical operation, but we can do better with more space: # define isdigit(c) table[c] This works and faster, but somewhat wasteful. We need only one bit to represent true or false, but we use a int. So what to do? There are many similar functions like isalpha(), isupper ... in c header file, so we can combine them into one int and get result by table[c]&SOME_BIT , which is what source do. Source code of ctype.h : # define _ISbit(bit) (1 << (