<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
	>

<channel>
	<title>rusidi &#039;n lina &#187; distributed database</title>
	<atom:link href="http://ucid.wordpress.com/category/distributed-database/feed/" rel="self" type="application/rss+xml" />
	<link>http://ucid.wordpress.com</link>
	<description>me, my wife and my job</description>
	<lastBuildDate>Thu, 26 Nov 2009 04:11:56 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<cloud domain='ucid.wordpress.com' port='80' path='/?rsscloud=notify' registerProcedure='' protocol='http-post' />
<image>
		<url>http://www.gravatar.com/blavatar/9b50809d10382cfded104c7b7e30aaf8?s=96&#038;d=http://s.wordpress.com/i/buttonw-com.png</url>
		<title>rusidi &#039;n lina &#187; distributed database</title>
		<link>http://ucid.wordpress.com</link>
	</image>
	<atom:link rel="search" type="application/opensearchdescription+xml" href="http://ucid.wordpress.com/osd.xml" title="rusidi &#039;n lina" />
		<item>
		<title>Concurrency Control in Database Systems</title>
		<link>http://ucid.wordpress.com/2006/12/26/concurrency-control-in-database-systems/</link>
		<comments>http://ucid.wordpress.com/2006/12/26/concurrency-control-in-database-systems/#comments</comments>
		<pubDate>Tue, 26 Dec 2006 02:53:50 +0000</pubDate>
		<dc:creator>ucid</dc:creator>
				<category><![CDATA[distributed database]]></category>

		<guid isPermaLink="false">http://ucid.wordpress.com/2006/12/26/concurrency-control-in-database-systems/</guid>
		<description><![CDATA[ 
 
 Ketika multiple user mengakses multiple objek basis data yang berada pada multiple site di sistem basis data terdistribusi, maka permasalahan kontrol konkurensi akan terjadi.Konflik terjadi apabila sekumpulan read dari satu transaksi berpotongan dengan sekumpulan read dari transaksi lainnya, dan/atau sekumpulan write dari satu transaksi berpotongan dengan sekumpulan write dari transaksi lainnya. Transaksi [...]<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=ucid.wordpress.com&blog=634987&post=4&subd=ucid&ref=&feed=1" />]]></description>
			<content:encoded><![CDATA[<div class='snap_preview'><br /><p class="MsoNormal" align="left"><span> </span></p>
<p class="MsoNormal" align="left"><span> </span></p>
<p class="MsoNormal" align="left"> <span></span><span>Ketika multiple user mengakses multiple objek basis data yang berada pada multiple site di sistem basis data terdistribusi, maka permasalahan kontrol konkurensi akan terjadi.Konflik terjadi apabila sekumpulan <em>read</em> dari satu transaksi berpotongan dengan sekumpulan <em>read</em> dari transaksi lainnya, dan/atau sekumpulan <em>write</em> dari satu transaksi berpotongan dengan sekumpulan <em>write</em> dari transaksi lainnya. Transaksi T1 dan T2 dikatakan konflik jika kedua-duanya dieksekusi pada waktu yang bersamaan. Bila T1 telah selesai sebelum T2 dikirim ke sistem, dalam kasus ini sekumpulan read dan write saling memotong, tidak dianggap konflik. Konflik diperhatikan pada sekumpulan write yang saling memotong di antara dua transaksi. Ada tiga pendekatan secara umum untuk mendesain algoritma kontrol konkurensi:</span></p>
<p class="MsoNormal" style="margin-left:0.25in;text-indent:-0.25in;" align="left"> <!--[if !supportLists]--><span><span>1.<span>      </span></span></span><!--[endif]--><em><span>Wait</span></em><!--[if !supportLists]--><span>. Jika dua transaksi konflik, transaksi yang konflik harus menunggu sampai transaksi lainnya selesai.</span></p>
<p align="left"><span><span>2.<span>      </span></span></span><!--[endif]--><em><span>Timestamp</span></em><span>. Urutan eksekusi transaksi berdasarkan <em>timestamp</em>. Setiap transaksi memiliki <em>timestamp</em> yang unik dan dua transaksi yang konflik diselesaikan berdasarkan urutan <em>timestamp</em>. <em>Timestamp</em> dapat diletakkan di awal, tengah, atau akhir eksekusi. Pendekatan berdasarkan <em>version</em> digunakan untuk menentukan <em>timestamp</em> objek basis data.</span></p>
<p class="MsoNormal" align="left"><span> </span></p>
<p class="MsoNormal" align="left"><span> </span></p>
<p class="MsoNormal" align="left"><span> </span></p>
<p class="MsoNormal" align="left"><span> </span></p>
<p class="MsoNormal" align="left"><!--[if !supportLists]--><span><span>3.<span>      </span></span></span><!--[endif]--><em><span>Rollback</span></em><span>. Dua transaksi yang konflik, salah satu transaksinya diulang kembali pengerjaannya. </span><!--[if !supportLists]--><span>Disebut juga <em>optimistic</em>, karena bila terjadi konflik maka beberapa transaksi akan di-<em>rollback</em>. Algoritma berdasarkan Mekanisme <em>Wait</em><br />
Sistem akan melakukan <em>lock</em> pada entitas basis data. Ada dua tipe <em>lock</em>:<br />
<span>1.<span>      </span></span></span><!--[endif]--><em><span>Readlock</span></em><!--[if !supportLists]--><span>. Transaksi akan mengunci entitas pada mode <em>shared</em>. Sehingga transaksi lain yang menunggu untuk membaca beberapa entitas juga bisa mendapatkan <em>readlock</em>.</span></p>
<p class="MsoNormal" style="margin-left:0.25in;text-indent:-0.25in;" align="left"><span><span>2.<span>      </span></span></span><!--[endif]--><em><span>Writelock</span></em><span>. Transaksi akan mengunci entitas pada mode eksklusif. Jika ada satu transaksi akan melakukan penulisan pada entitas yang telah di-<em>writelock</em>, maka transaksi lainnya tidak boleh mendapatkan <em>readlock</em> maupun <em>writelock</em> pada entitas ini.</span><br />
<em><span>Lock</span></em><span> akan menimbulkan masalah baru. <em>Livelock</em> dan <em>deadlock</em>. <em>Livelock</em> terjadi ketika suatu transaksi berkali-kali gagal dalam mendapatkan <em>lock</em>. <em>Deadlock</em> terjadi ketika beberapa transaksi melakukan <em>lock</em> pada beberapa entitas pada saat yang bersamaan; setiap transaksi mendapatkan <em>lock</em> dari entitas yang berbeda dan saling menunggu transaksi lainnya untuk melepaskan <em>lock</em>.</span><br />
<em><span>Deadlock </span></em><span>dapat diatasi dengan:</span></p>
<p class="MsoNormal" align="left"><em><span> </span></em></p>
<p class="MsoNormal" align="left"><span> </span></p>
<p class="MsoNormal" style="margin-left:0.25in;text-indent:-0.25in;" align="left"><span><span>1.<span>      </span></span></span><!--[endif]--><span>Setiap transaksi melakukan <em>lock</em> pada semua entitas sekali. </span><!--[if !supportLists]--><span>Jika ada beberapa <em>lock</em> yang digunakan oleh beberapa transaksi lainnya, maka transaksi akan melepaskan semua <em>lock</em> yang ada. <span>2.<span>      </span></span></span><!--[endif]--><span>Membuat order linier secara acak pada item-item, dan semua transaksi melakukan urutan <em>request </em>berdasarkan order ini.</span></p>
<p class="MsoNormal" style="margin-left:0.25in;text-indent:-0.25in;" align="left"><span></span><br />
<em><span>Deadlock</span></em><br />
<span>ini sangat jarang terjadi, sehingga akan lebih efektif ditanggulangi ketika telah terjadi daripadamelakukantindakan preventif dari awal yang memakan biaya lebih besar.Protokol sederhana yang diperlukan, sehingga setiap transaksi dapat memenuhi aturan keberlanjutan adalah <em>two-phase locking</em> (2PL).<span></span></span></p>
<p align="left"><span><span>1.<span>      </span></span></span><!--[endif]--><span>Fase <em>locking</em>. Transaksi mengambil <em>lock</em> tanpa melepasnya.</span></p>
<p class="MsoNormal" align="left"><span> </span></p>
<p class="MsoNormal" align="left"><span> </span></p>
<p class="MsoNormal" align="left"><span> </span></p>
<p class="MsoNormal" align="left"><span> </span></p>
<p class="MsoNormal" align="left"><span> </span></p>
<p class="MsoNormal" style="margin-left:0.25in;text-indent:-0.25in;" align="left"><!--[if !supportLists]--><span><span>2.<span>      </span></span></span><!--[endif]--><span>Fase <em>unlocking</em>. Dalam fase ini, transaksi melepaskan <em>lock </em>yang ada dan tidak boleh mengambil <em>lock</em>.</span><br />
<em><span>lockpoint</span></em><!--[if !supportLists]--><span> merupakan keadaan sesaat sebelum pelepasan <em>lock</em> yang pertama kali dilakukan. Algoritma berdasarkan Mekanisme <em>Timestamp .</em>Untuk mendapatkan <em>timestamp</em> unik untuk transaksi pada node berbeda di sistem terdistribusi, <em>clock</em> setiap node harus disamakan. Untuk menyelaraskan <em>clock</em> dapat digunakan <em>message passing</em>. Algoritma berdasarkan Mekanisme <em>Rollback/Optimistic.</em><br />
Terdapat 4 fase eksekusi transaksi pada pendekatan kontrol konkurensi <em>optimistic</em>:</span></p>
<p align="left"><span><span>1.<span>      </span></span></span><!--[endif]--><em><span>Read</span></em><span>. </span><span>Proses membaca tidak terlalu dibatasi. Hasilnya diletakkan pada variabel lokal. </span><span>Sekumpulan <em>read</em> tergantung juga pada proses validasi.</span></p>
<p align="left"><!--[if !supportLists]--><span><span>2.<span>      </span></span></span><!--[endif]--><em><span>Compute</span></em><span>. Transaksi menghitung sekumpulan nilai dari data entitas yang disebut sekumpulan <em>write</em>. Hasilnya diletakkan pada variabel lokal.</span></p>
<p align="left"><!--[if !supportLists]--><span><span>3.<span>      </span></span></span><!--[endif]--><em><span>Validate</span></em><span>. Sekumpulan <em>write </em>dan <em>read</em> transaksi lokal divalidasi oleh sekumpulan transaksi yang sedang berjalan.</span></p>
<p class="MsoNormal" align="left"><!--[if !supportLists]--><span><span>4.<span>      </span></span></span><!--[endif]--><em><span>Commit and Write</span></em><span>. Setelah berhasil divalidasi, akan dijalankan di sistem dan diberikan <em>timestamp</em>. Sekumpulan <em>write</em> akan diubah menjadi variabel global dan nilainya dikirim ke setiap node. </span><span>Jika tidak berhasil divalidasi, transaksi diulangi lagi dari fase <em>compute </em>atau <em>read</em>.</span><br />
<em><span></span></em><span>Evaluasi Performansi dari Algoritma Kontrol Konkurensi  </span></p>
<p class="MsoNormal" align="left"><span>Derajat Konkurensi<br />
</span><em><span>Serial history </span></em><span>memiliki derajat konkurensi yang rendah, sedangkan pendekatan 2PL dan <em>optimistic </em>memberikan derajat konkurensi yang lebih tinggi. Tingkat Lanjut untuk Peningkatan Konkurensi </span><em><span>Timestamp</span></em><span> yang Multidimensional Protokol ini memungkinkan transaksi untuk memiliki vektor <em>timestamp</em> sampai k elemen. Maksimum k diperoleh dari dua kali jumlah maksimum operasi pada satu kali transaksi.</span></p>
<p align="left"> <span>Relaksasi dari <em>Two-Phase Locking</em></span></p>
<p align="left"><em><span> </span></em><span>Suatu transaksi dapat melepaskan suatu <em>lock</em>, sebelum transaksi ini me-<em>request</em> beberapa <em>lock </em>lagi. Pada transaksi berikutnya yang mengambil <em>lock</em> ini, <em>lock</em> tidak dapat dilepaskan sampai transaksi sebelumnya tidak lagi me-<em>request lock</em>.<br />
</span><em><span>System Defined Prewrites</span></em></p>
<p class="MsoNormal" align="left"><span> </span><em><span>Prewrite</span></em><span> menunjukkan bahwa value dari transaksi akan di-<em>write</em> disaat yang akan datang. <em>Prewrite</em> tidak akan mengubah status objek data. Ketika <em>prewrite</em> dari suatu transaksi dilakukan, transaksi akan melakukan operasi <em>precommit</em>. </span><span>Setelah tahapan ini, transaksi lain dapat membaca <em>prewrite</em>, walaupun transaksi ini belum di-<em>update</em> dan di-<em>commit</em>. Dengan <em>prewrite,</em> sistem yang terdiri dari transaksi berdurasi panjang maupun pendek dapat diseimbangkan, sehingga tidak ada delay untuk transaksi berdurasi pendek. </span></p>
<p class="MsoNormal" align="left"><span>Transaksi yang Fleksibel</span></p>
<p class="MsoNormal" align="left"><span>Memungkinkan spesifikasi dari beberapa alternatif subset dari subtransaksi untuk dieksekusi dan menghasilkan eksekusi yang berhasil dalam satu dari beberapa alternatif subset tersebut. Eksekusi dari transaksi yang fleksibel dapat diproses dalam beberapa cara. </span></p>
<p align="left"><span>Kontrol Konkurensi yang dapat Disesuaikan</span></p>
<p align="left"><span> Sistem basis data yang ada, saling terhubung dengan sistem basis data terdistribusi yang heterogen. Penggunaan konsep sistem basis data </span><em><span>Reliable, Adaptable, Interoperable, Distributed</span></em><span> (RAID), menjadi fasilitas dalam metode kontrol konkurensi. Model umum untuk pendekatan terhadap sistem dan transaksi yang berbeda adalah dengan <em>generic</em> <em>state</em>, <em>converting</em> <em>state</em>, dan <em>suffix</em> <em>sufficient</em> <em>state</em>.</span></p>
<p align="left"><span> Kesimpulan</span></p>
<p align="left"><span> Kontrol konkurensi adalah masalah yang timbul ketika beberapa proses terjadi pada berbagai tempat di sistem. Solusi awal untuk hal ini adalah dengan memastikan kelas-kelas <em>serializability</em>,<em> two-phase locking</em>,<em> </em>dan formalisasi pendekatan <em>optimistic</em>. Mekanisme populer untuk kontrol konkurensi adalah <em>two-phase locking</em>. Kontrol konkurensi yang dapat disesuaikan diimplementasikan pada sistem RAID. </span><span>Penelitian diharapkan berlanjut, pada bidang semantik dari transaksi dan terutama pada sistem yang berorientasi objek. </span><span>Pada sistem berskala besar, sangat sulit untuk mem-blok akses ke objek basis data untuk melakukan transaksi. Locking pada masa yang akan datang tidak akan relevan lagi pada kasus seperti ini.</span></p>
<p class="MsoNormal" align="left"><span> </span></p>
<img alt="" border="0" src="http://feeds.wordpress.com/1.0/categories/ucid.wordpress.com/4/" /> <img alt="" border="0" src="http://feeds.wordpress.com/1.0/tags/ucid.wordpress.com/4/" /> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/gocomments/ucid.wordpress.com/4/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/comments/ucid.wordpress.com/4/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/godelicious/ucid.wordpress.com/4/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/delicious/ucid.wordpress.com/4/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/gostumble/ucid.wordpress.com/4/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/stumble/ucid.wordpress.com/4/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/godigg/ucid.wordpress.com/4/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/digg/ucid.wordpress.com/4/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/goreddit/ucid.wordpress.com/4/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/reddit/ucid.wordpress.com/4/" /></a> <img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=ucid.wordpress.com&blog=634987&post=4&subd=ucid&ref=&feed=1" /></div>]]></content:encoded>
			<wfw:commentRss>http://ucid.wordpress.com/2006/12/26/concurrency-control-in-database-systems/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
	
		<media:content url="http://1.gravatar.com/avatar/d3920c6ab9c66a017bd5c5798aa1776d?s=96&#38;d=identicon&#38;r=G" medium="image">
			<media:title type="html">ucid</media:title>
		</media:content>
	</item>
	</channel>
</rss>