[펌]Concurrency control mechanism

2PC(2 phase commit) protocol에 대한 글을 찾다가 CC(Concurrency control)에 대한 그림을 발견해서 퍼 옴

 

 

Figure 3: Classifications of concurrency control mechanisms  

..more

>접기

Concurrency control mechanism

 

Concurrency control maintains the consistency and isolation properties of transactions. This is the responsibility of the User/application, so we will not give a detailed description of concurrency control here (but see chapter 11 in [11]). However, as NFR provides Locks as the tool for building concurrency control, we will provide a brief overview of locking-based concurrency control and show how it can be implemented on top of NFR.

 

Figure 3: Classifications of concurrency control mechanisms.

 

The main categories of concurrency control mechanisms are shown in figure 3. Pessimistic algorithms synchronize the concurrent executions of transactions early in their execution life cycle, whereas Optimistic algorithms delay the synchronization for transactions until their termination.

 

Figure 4: Strict two-phase locking.

 

The main idea behind locking-based concurrency control is to ensure that the data shared by conflicting transactions is accessed by one operation at a time. This is accomplished by associating a lock with each data unit, and not allowing a transaction to access the data unit if a lock has been created on it by another transaction. One often-used locking scheme is (pessimistic) strict two-phase locking (2PL, figure 4). It is popular because it is relatively simple to implement and avoids cascading aborts¹¹. Strict 2PL acquires locks before data items are accessed, holds all locks until all accesses are finished, and releases all locks at once when the transaction commits/aborts. An NFR application can implement strict 2PL like this: While the transaction is executed, ask NFR to create Locks on Files before they are accessed. When the transaction commits/aborts, ask NFR to remove all Locks.

 

To conclude, we list some possible applications and the locking schemes they are likely to use:

 

Application	Likely locking scheme
Distributed Database	Strict 2PL.
Distributed Data-mart	None, updates are made by infrequent, sequential writes.
CVS	Strict 2PL.
Distributed Filesystem	User-defined, depends on environment/usage pattern.
Web Cache	None, same as Distributed Data-mart.
DNS	None, Same as above.
=
=Distributed object persistency system	User-defined, could be different for each class of objects.

 

출처 : http://www.vermicelli.pasta.cs.uit.no/ipv6/students/andrer/doc/html/node20.html