Tag Archives: definition

SQL Server Concurrency Effects

Lost Update

Happens when one transaction update overwrites another, causing the update to be lost.

Dirty Reads

Reading uncommitted records.

Phantom Reads

Reading while another transaction is adding new record, result in different number of rows being returned.

Repeatable Reads

When the same query to read is executed, it will return the same result.



Leave a comment

Posted by on May 22, 2018 in General


Tags: , , , ,

Columnstore Index

  • New in SQL Server 2012.
  • Stored by columns, a column-based index, instead of row-based like in traditional index. For example, if row-based index is consisted of Firstname and Lastname columns, the column-based index would have 2 different indexes: Firstname in its own index and Lastname in its own index.
  • The index is compressed, allowing high performance.
  • The compressed data is stored in-memory, reducing needs to read off the disks.
  • Compression ratio is generally high because the same data type in a column.
  • Generally a better choice for wide table with many columns, as commonly found in data warehouse tables.
  • Clustered and non-clustered index.
  • Can be combined with row-based index.

Microsoft Docs

Leave a comment

Posted by on May 16, 2018 in General


Tags: , , , , ,

Optimistic Concurrency x Eventual Consistency

Optimistic Concurrency

Less strict locking to support more simultaneous access. In optimistic concurrency, multi users are able to perform actions on the same resources without locking each other, for example, one user can write without locking another user that’s reading the same resource. Some actions will still lock the resource exclusively, for example, a schema changes.

Pessimistic Concurrency

Is the opposite, a stricter locking is used. When a user is performing an action that requires lock, other users won’t be able to do anything that would conflict with the lock, until the lock is release from the owner (first user).

Eventual Consistency

Eventual consistency guarantees more of availability than consistent data. This is achieved by prioritize availability (not locking the resource) rather than replicating the data.

Strong Consistency

The opposite of eventual consistency where it’s prioritizing consistent data across the system rather than availability.


Eventual consistency is classified as BASE (Basically Available, Soft state, Eventual consistency) semantics, as oppose to ACID principle.


Eventual / strong consistency is similar to optimistic / pessimistic concurrency. The difference is the terms eventual / strong consistency is often used in a distributed system where optimistic / pessimistic concurrency is used more in lower level, single entity such as database.

Azure Cosmos DB consistency levels, strong to weakest consistency:
– Strong consistency
– Bounded staleness
– Session
– Consistent prefix
– Eventual consistency

Leave a comment

Posted by on May 12, 2018 in General


Tags: , , , , ,

Mutual Exclusion

The requirement of ensuring that no two concurrent processes are in their critical section at the same time; it is a basic requirement in concurrency control, to prevent race conditions.

Source: Wikipedia

Leave a comment

Posted by on June 23, 2015 in General


Tags: ,

Producer-consumer Problem

Two processes, the producer and the consumer, who share a common, fixed-size buffer used as a queue. The producer’s job is to generate a piece of data, put it into the buffer and start again. At the same time, the consumer is consuming the data (i.e., removing it from the buffer) one piece at a time. The problem is to make sure that the producer won’t try to add data into the buffer if it’s full and that the consumer won’t try to remove data from an empty buffer.

While it may sound like a simple problem, the solution is not as easy. Not even simple. There are many sub-impediments you have to watch:

  • Locking / unlocking mechanism.
  • Multiple access to the semaphore.
  • Concurrency and mutual exclusion / race conditions.

Source: Wikipedia

Leave a comment

Posted by on June 17, 2015 in General


Tags: ,

Boxing x Unboxing

Boxing and unboxing is not to be confused with downcast / upcast.

  • Boxing is the process of converting a value type to the type object or to any interface type implemented by this value type.
  • When the CLR boxes a value type, it wraps the value inside a System.Object and stores it on the managed heap.
  • Unboxing extracts the value type from the object.
  • Boxing is implicit
  • Unboxing is explicit.
  • The concept of boxing and unboxing underlies the C# view that a value of any type can be treated as an object.



int i = 123;
// The following line boxes i. 
object o = i;


o = 123;
i = (int)o;  // unboxing

Reference: MSDN

Leave a comment

Posted by on June 5, 2015 in General


Tags: , , , ,

Software Laws

I was looking for a specific theorem called CAP theorem, but came across these interesting, sort of funny but somewhat true, software laws.

I think these laws are useful to get better understanding of philosophy behind a software or computer science in general.

  • Atwood’s Law

    Any software that can be written in JavaScript will eventually be written in JavaScript.

  • Brooks’s Law

    Adding manpower to a late software project makes it later.

  • Conway’s law

    Any piece of software reflects the organizational structure that produced it.

  • Miller’s law

    To understand what another person is saying, you must assume that it is true and try to imagine what it could be true of.

  • Wirth’s law

    Software gets slower faster than hardware gets faster.

Leave a comment

Posted by on March 1, 2015 in General


Tags: , , , ,

%d bloggers like this: