Last week Team Idea Workshop gave us the lecture “Transaction”, transaction is a series of work done in a DBMS(Database Management System), in order to keep the database’s consistent and isolation (something like independence, which is really important in database design according to E.F Codd’s paper), I want to place transaction in our course map.

  According to the map, transaction is between storage & querying and application design, that is to say, it is a bridge between the bottom design of database and application design in the higher level.

Part I ACID Properties

  However, not all operations on database are transaction, and operations with properties ACID are defined as transactions.

  A: Atomic, this property reveals the entirety property of transaction, that is to say, all the operations in a transaction are done, or none of them is implemented. If a transaction fails to implement all the operations, none of the operations will be aborted and nothing will be changed in the database.

  C: Consistency, to preserve the consistency of a database, a transaction should be of consistency, which means the constraints defined in the operations of a transaction must guarantee that the route of status it brings is one and only, so the constraints are enough to lead to a unique status.

   I: Isolation, I think this is a must to guarantee consistency, only if transactions cannot influence each other, consistency can be kept. What’s more, operations with this property and atomic property can be managed more easily.

  D: Durability, if a transaction implements successfully, all the changes brought by this transaction persists, which means the change is made no matter if the transaction or the database has bugs.

Part II Serializability

  Serializability is a property of transaction schedule. Schedule the execution sequences, just like a workflow of a operation. And using schedule with concurrency improves resource utilization and reduce waiting time, thus enhance performance with same I/O and CPU. Two methods of serializability were introduced in the lecture, namely conflict serializability and view serializability.

  Any schedule that is conflict-serializable is also view-serializable, but not necessarily the opposite. So we can say that conflict-serializability is a special case of view serializability. Here conflict serializability is explained in detail.

  When two schedules have the same sets of respective chronologically-ordered pairs of conflicting operations, it is conflict serializable, and the serials use different data, but both of them read data A, at least one of them write on it.

Part III Lock & Lock-based Protocols

  At first some basic concepts are introduced. 

  Lock: A lock is a mechanism to control concurrent access to a data item. A lock is needed when a transaction want to get accessibility to data. And the lock should be released when the transaction is over.

  Shared-mode lock(S): Under this kind of lock, data can be read but can not be written.

  Exclusive-mode lock(X): Under kind of lock, data can be read and written.

  Lock Manager: If a transaction wants to get a lock on data , It must apply to a component called lock manager. Lock manager is in charge of granting of lock.

  The granting of lock obeys these principles :

  Principle 1: There is no other transaction holding a lock on Q in a mode that conflicts with M

  Principle 2: There is no other transaction that is waiting for a lock on Q and that made its lock request before T.

  Protocol is based on the previous lock and principle of granting.

  Two-phase locking protocol includes two phases, which is growing phase where a transaction may only obtain locks and shrinking phase where to release locks. And in strict two-phase locking protocol exclusive-mode lock shall be held until transaction commits. And in Rigorous two-phase locking protocol all locks shall be held until transaction commits. In consequence, strict two-phase locking protocol increases the safety and consistency of database, while Rigorous two-phase locking protocol can ensure serializability of transactions.

Part III Insert and Delete Operations

Operations in transactions can be classified like this.

My thoughts

Why transactions are important in cloud computing and DDBS(Distributed Database System) is briefly introduced in the lecture. I think transaction is like a application package, the key to maintain the database’s safe and consistency are ACID properties and lock-based protocol is necessary to give different rights to different transactions operating on different kinds of data. When using cloud computing to share information on a platform, transactions need to be efficient and safe, SVN may need may of the read operations on different client and write operations on servers, consistency of the whole information framework is very important when we do all of these things, so some ideas of transactions and the technology it uses is necessary and attractive in this matter.