I * d
- .
,
PERBAIKAN DAN EVALUASI KINERJA ALGORITMA
READ-COMMIT ORDER CONCURRENCY CONTROL
(ROCC)
S U L A S N O
PROGRAM PASCASARJANA
TNSTITUT PERTANIAN BOGOR
BOGOR
1
SURAT PERNYATAAN
Dengan ini menyatakan bahwa tesis saya yang berjudul
:Perbaikan dan Evalusi
Kinerja Algoritma
Rend-commit Order Concurrency Control
(ROCC) adalah
merupakan hasil karya saya sendiri dan belum pernah dipublikasikan. Sumber
informasi yang berasal atau dikutip dari karya yang diterbitkan maupuil tidak
diterbitkan dari penulis lain telah disebutkan dalam teks dan dicantumkan dalam
daftar pustaka di bagian akhir tesis ini.
ABSTRAK
SULASNO. Perbaikan dan Evaluasi Kinerja Algoritma
Read-comnzit Order
Concurrency Control
(ROCC).
Dibiinbing ole11 FAHREN BUKHAFU dan KUDANG
BORO SEMINAR.
Concurrency control
(CC)
inerupakan suatu mekanisme untuk mengatur eksekusi
transaksi-transaksi yang terjadi dalam basis data.
CC
pada produk komersial
menggunakan
Strict Two Phase Locking
(Strict 2PL). Strict 2PL
masih mempunyai
masalah yang disebut dengan
deadlock.
Read-com~izit Order Concunency Control
(ROCC)
merupakan suatu
CC
baru
yang diharapkan dapat ~nemberikan
kinerja yang tinggi dan memperbaharui
CC
yang
telah ada. Namun
ROCC
yang telah dikembangkan masih terdzpat kelemahan
terutama yang berkaitan dengan masih terdapatnya
restart
terhadap eksekusi
transaksi yang bersifat
seriulizable.
Untuk itu pada penelitian ini, teIah dilakukan
perbaikan algoritma
ROCC (ROCCM),
serta evaluasi kinerja algoritma
ROCC,
ROCCM
dan
Strict ZPL,
melalui simulasi.
Hasil simulasi memperlihatkan bahwa
ROCCM,
mempunyai
throughput
yang
lebih baik, bila dibandingkan dengan
ROCC
dan
Strict
2PL.
Melalui perbaikan
algoritma validasi
intervening
yang terdapat pada
ROCC,
inaka dihasilkan algoritma
ROCCM
yang mempunyai kinerja lebih baik.
ABSTRACT
SULASNO. Revision and evaluation of performance Read-commit Order
Concurrency Control
(ROCC)
algorithm. Supervised by FAHREN BUKHARI and
KUDANG BORO SEMINAR.
Concurrency control
(CC)
is
a
mechanism to manage simultaneous operations on
a database. The commercial databases use Strict Two Phase Locking (Strict
2PL) CC
to maintain execution correctness. Unfortunately Strict
2PL
cannot meet a very high
performance of a database system, due to Strict
2PL
thrashing behavior caused by
blocking.
The Read-commit Order Concurrency Control
(ROCC)
is a new method of
CC
for high performance database systems. Unfortunately
ROCC
that has been
developed still has weakness, it has a restart for serializable execution. Modified
ROCC (ROCCM)
is done by reengineering validation algorithm to minimize restart
to increase throughput.
The performance of
ROCC, ROCCM,
and Strict
2PL
is analized by a
simulation program. Our simulation result shows that
ROCCM
produces much
higher system throughput compared with
ROCC,
and Strict
2PL.
OHak cipta milik Sulasno, tahun 2006
Hak cipta dilindungi
Dilarang rnengutip dun menzperbanyak tanpa ijin tertulis dari
Institut Perlanian Bogor, sebigian atau seluruhnya dalam
v
PERBAIKAN DAN EVALUASI KINERJA ALGORITMA
READ-COMMIT ORDER CONCURRENCY CONTROL
(ROCC)
S U L A S N O
Tesis
Sebagai salah satu syarat untuk memperoleh gelar
Magister Sains pada
Program Studi Ilmu Komputer
PROGRAM PASCASARJANA
INSTITUT PERTANIAN BOGOR
BOGOR
Judul
Nama
NIM
:
Perbaikan dan Evaluasi Kinerja Algoritma
Rearl-comnzit Order Coitcr~rrency
Control
(ROCC)
: S u l a s n o
:
G651024074
Ir. Fahren Bukhari, M.Sc.
Ketua
Disetujui,
Konlisi Pembimbing
Anggota
Diketahui,
frida Manuwoto, M.Sc.
vii
PRAKATA
Puji dan Syukur Penulis panjatkan ke Hadirat Allah SWT atas segala karunia-Nya
sehingga karya ilmiah ini berhasil diselesaikan. Tema yang dipilih dalam penelitian
yang dilaksanakan sejak bulan Agustus 2004 ini ialah algoritma
concurrency control
dengan judul
:"Perbaikan dan Evaluasi Kineja Algoritma
Read-commit Order
Concurrency Control (ROCC)".
Terima kasih penulis ucapkan kepada Bapak Ir. Fahren Bukhari, M.Sc. dan Bapak
Dr. Ir. Kudang Boro Seminar, M.Sc. yang telah banyak memberi saran. Disamping itu
penghargaan disampaikan kepada seluruh staf Bidang Sistem dan Jaringan Komputer,
Pusat Pengembangan Informatika Nuklir, Badan Tenaga Nuklir Nasional Jakarta,
yang telah banyak memberikan semangat dalam melakukan penelitian ini.
Ucapan terima kasih juga disampaikan kepada rekan-rekan mahasiswa program
pascasarjana ilmu komputer IPB, terutama angkatan kedua yang telah memberikan
kerjasama yang baik selama mengikuti kuliah sampai dengan penyusunan tesis ini.
Akhirnya ucapan teriina kasih disampaikan kepada istri tercinta dan putralputriku atas
segala doa dan dukungannya.
Semoga karya ilmiah ini bermanfaat.
Bogor, Pebruari 2006
DAFTAR
RIWAYAT HIDUP
Penulis dilahirkan di Kebumen Jawa Tengah pada tanggal 20 Mei 1967 sebagai
anak ke empat dari pasangan Amad Kasim dan Ibu Khosiyah (Alm). Pendidikan
Sarjana ditempuh dari Jurusan Teknik Informatika Universitas Budi L u h u Jakarta,
lulus pada tahun 1996. Kesempatan untuk n~elanjutkan program Pascasarjana pada
program studi Ilmu Kon~puter,
FMIPA, IPB, diperoleh pada tahun 2002 dengan biaya
sendiri.
Penulis bekerja di Pusat Pengembangan Informatika Nuklir, Badan Tenaga Nuklir
Nasional (BATAN) Jakarta sejak tahun 1990. Tanggung jawab yang dipegang
DAFTAR IS1
Halaman
DAFTAR TABEL
...
xi
DAFTAR GAMBAR
...
xii
...
DAFTAR LAMPIRAN
...
xu1
I
.
PENDAHULUAN
...
1
...
I
.
1
.
Latar Belakang
. .
1.2
Tujuan Penelltian
...
2
1.3. Ruang Linglup
...
2
...
I1
.TINJAUAN PUSTAKA
11.1. Basis Data dan
Dalabase Manageirzent System
(DBMS)
...
...
11.2. Sistem Basis Data
...
113
.
Transaksi
.
. ...
11.4.
Serializabzlzly
...
11.5.
Conczrrrency Conll.01
(CC)
...
IL6
.
Two Phase Locking
(2PL)
...
11.7.
Strict Two Phase Locking
(Strict 2PL)
...
11.8.
Read-conznzit Order Concurrel~cy
Control
(ROCC)
111
.
METODE PENELITIAN
...
15
111.1. Metode Perbaikan Algoritma
ROCC
...
15
IV. HASIL DAN PEMBAHASAN..
...
IV.1. Algoritina
ROCCM..
...
,.
...
...
IV.2. Pelaltsailaan Simulasi..
.
.
IV.3. I-Ias~l S~~uulasi.
...
...
IV.4. Evaluasi Kineqja Algorit~na
...
V. KESIMPULAN
...
V.
1.
Kesimpula~.
...
V.2. Saran
DAFTAR TABEL
Halaman
Tabel
1
.
Ko~npatibilitas
modus
lock
...
7
Tabel 2
.
Parameter-parameter input simulasi
...
16
Tabel
3
.
Nilai parameter input default pada pelaksanaan simulasi
...
26
[image:12.539.51.481.40.732.2]DAFTAR GAMBAR
...
Gambar 1
.
Komponen sistenl basis data terpusat
Gambar 2
.Contoh eksekusi transaksi secara serial
...
Gainbar 3
.
Coiltoh eksekusi transaksi secara
seriulizable
...
Ganlbar
4
.
Grafik
Strict 2PL
...
Gambar 5
.
Contoh eksekusi transaksi pada
Strict 2PL
...
Gainbar 6
.
Contoh deadlockpada
Strict 2PL
...
Gambar
7
.
Format elen~en
RC-queue
...
Ga~nbar
8
.
RC-queue
pada
ROCC
...
Gan~bar
9
.
Komponen
ROCC
...
Ganlbar 10
.
RC-queue
dengan eksekusi
serializuble
pada
ROCC
...
Gambar 11
.
Acyclic
SG
...
Gambar 12
.
RC-queue
pada algoritma
ROCCM
...
Gambar 13
.
Model
logical queuing
untuk
ROCC
dan
ROCCM
pada
simulator
...
...
Gambar 14
.Model
logical queuing
untuk
Strict 2PL
pada simulator
. .
DAFTAR LAMPIRAN
Halaman
La~npiran
1
.Hasil uji
t-student
perbedaan
throughput
algoritma
ROCC
dan
ROCCM
...
32
Lanlpiran 2
.
Listing
program roccm.cpp
...
33
La~llpiran
3
.
Listing
program roccn1.h
...
47
Latnpiran 4
.
Listing
program rocc.cpp
...
49
1.1. L a t a r Belakang
Transaksi dalam suatu sistem basis data merupakan sekumpulan operasi
read
dan
write.
Operasi
read
digunakan untuk membaca data, sedangkan
write
merupakan operasi menulis atau mengubah data. Pada basis data dengan
pengguna tunggal
(single tlser),
eksekusi transaksi dapat dilakukan tanpa ada
gangguan dari pengguna lain. Na~nun
pada basis data dengan pengguna banyak
(iizulti-user),
transaksi harus dapat dieksekusi secara bersamaan dan konflik antar
transaksi yang terjadi harus dapat diatasi. Konflik antar transaksi terjadi jika dua
atau lebih transaksi mangakses item data yang sama, dan paling sedikit satu dari
operasi transaksi tersebut adalah operasi
write.
Concurrency control (CC)
merupakan suatu mekanisme untuk mengatur
eksekusi transaksi-transaksi yang terjadi dalam basis data (Connoly
et al. 2002).
Secara umum mekanisme
CC
dibagi ~nenjadi
2
jenis yaitu
optimistic
dan
pessinzistic
(Ozsu
&Valduriez
1999). Optiiizistic
~nengasumsikan
bahwa konflik
antar transaksi jarang terjadi, sehingga mengijinkan transaksi-transaksi yang
datang dapat langsung diproses tanpa harus nienunggu validasi terlebih dahulu.
Pessinzistic
mengasumsikan bahwa konflik antar transaksi sering terjadi, karena
itu setiap transaksi harus melalui validasi terlebih dahulu. Dengan adanya
CC,
diharapkan eksekusi transaksi-transaksi yang ada dalam basis data dapat dikelola,
sehingga konsistensi basis data dapat tetap terjaga.
Menurut Shi dan Perrizo
(2004), CC
yang telah banyak digunakan pada produk
komersial adalah
Two Phase Locking (2PL). 2PL
merupakan jenis
CC
yang
pessinzistic.
Pada
2PL
setiap transaksi harus mendapatkan kunci
(lock)
untuk item
data yang ingin diakses, dan melepas kembali kunci tersebut apabila transaksi
selesai dilakukan. Dengan demikian sebuah item data tidak dapat diakses oleh
suatu transaksi, jika item data tersebut telah dikunci oleh transaksi lain. Salah satu
jenis dari
2PL
yang telah banyak digunakan adalab
Stricf Two Phase Locking
(Strict
2PL).
Pada Strict
2PL
setiap transaksi harus mendapatkan kunci dari item
data yang ingin diakses, dan pelepasan kembali semua kunci dilakukan secara
2
dilakukan. Pada Strict
2PL
masih terdapat masalah yang disebut dengan
deadlock
yaitu suatu kondisi yang terjadi jika ada dua atau lebih transaksi saling
menunggu dan saling memblokir.
Shi dan Perrizo (2004), telah mengembangkan C C
optinzistic
baru yaitu
Read-
conzmit Order Concurrency Control
(ROCC) yang diharapkan dapat
memperbaharui C C yang telah ada. Namun R O C C yang telah dikembangkan
masih terdapat kelemahan terutama yang berkaitan dengan masih terdapatnya
restart
(eksekusi transaksi yang dihentikan untuk kemudian diproses ulang)
terhadap eksekusi transaksi yang bersifat
serializable.
Untuk itu maka pada
penelitian ini, akan dilakukan perbaikan algoritma ROCC, serta evaluasi kinerja
algorittna ROCC, R O C C yang telah diperbaiki (ROCCM), dan Strict
2PL
melalui simulasi
1.2.
Tujuan Penelitian
Penelitian ini bertujuan untuk melakukan perbaikan algoritma ROCC, serta
melakukan evaluasi kinerja. Evaluasi kinerja dilakukan terhadap algoritma
ROCCM, algoritma ROCC, maupun algoritma yang telah banyak dipakai pada
produk komersial yaitu Strict
2PL.
Evaluasi kinerja dilakukan melalui simulator
yang diterapkan pada basis data terpusat. Hal tersebut disesuaikan dengan
karakteristik algoritma yang lebih cocok diaplikasikan pada basis data terpusat.
1.3.
Ruang lingkup
Penelitian perbaikan algoritma ROCC, hanya dilakukan terhadap masalah
reslart,
yaitu masih terdapatnya masalah tersebut yang seharusnya tidak dilakukan
terhadap eksekusi
serializable.
Disamping itu evaluasi kinerja, hanya dilakukan
melalui pemodelan simulasi pada basis data terpusat. Berdasar hasil sitnulasi,
11.
TINJAUAN
PUSTAKA
11.1.
Basis Data dan Database Mariagentetzf Systet~i
(DBMS)
Menurut Elmasri dan Navathe
(2000),Basis data adalah kumpulan data yang
saling berhubungan, sedangkan database tnanagentent systenzs (DBMS) adalah
suatu kumpulan dari program-program yang memungkinkan para pengguna untuk
membuat dan mengelola sebuah basis data. Oleh karena itu, DBMS merupakan
perangkat lunak sistem yang memberikan fasilitas pendefinisian (dehing),
pengkontruksian (constructing), pemanipulasian (manipulating) basis data untuk
berbagai aplikasi basis data.
Pendefinisian basis data memerlukan tipe data, struktur dan batasan-batasan
untuk sebuah data yang akan disimpan dalam basis data. Pengkonstruksian basis
data adalah proses penyi~npanan
data pada media penyimpanan yang dikendalikan
oleh DBMS. Pemanipulasian basis data diantaranya berisi fungsi-fungsi seperti
querying pada sebuah basis data untuk mengakses ulang data, update basis data,
dan membuat laporan-laporan (reports) dari suatu data.
11.2.
Sistem Basis data
Menurut Bernstein el al. (1987), sistem basis data (database system, DBS)
adalah sekumpulan modul hardware dan sofhoare yang mendukung perintah-
perintah untuk mengakses basis data. Perintah-perintah untuk mengakses basis
data meliputi read dan write. Operator read (r(x)) lnerupakan perintah untuk
mengakses item data
x,
sedangkan write (iv(x))
merupakan perintah untuk
~nengubah
nilai item data
x.DBS harus mendukung operasi-operasi transaksi yaitu: start, comn~it, dan
abort. Start adalah permulaan eksekusi suatu transaksi baru. Berhentinya suatu
transaksi ditandai dengan operasi corntnit atau abort. Operasi comnzit
mengindikasikan bahwa suatu transaksi berhasil dieksekusi sampai selesai,
sedangkan abort menunjukkaan bahwa suatu transaksi tidak berhasil dieksekusi
sa~npai
selesai, dan semua operasi yang sudah dieksekusi akan dibatalkan (undo).
Menurut Bernstein et
al.
(1987), sebuah DBS berisi empat komponen yaitu
:4
manager
(CM).
Model DBS pada basis data terpusat diperlihatkan pada
Gainbar
1. Pada Gambar 1,
TM
berguna untuk menerirna permintaan operasi
basis data dan operasi transaksi yang kemudian akan disampaikan kepada
SC,
sedangkan
SC
adalah kutilpulan program yang mengendalikan eksekusi transaksi-
transaksi secara
concurrent.
SC
harus bisa mengeksekusi transaksi-transaksi
secara
serializable.
RM
bertanggung jawab untuk menjamin semua isi basis data
adalah merupakan efek dari transaksi yang telah
contnzil
bukan dari efek pada
transaksi yang mengalami
abort.
CM berguna untuk mengatur perpindahan data
antara memori dan media penyimpanan
(disk).
Tra,wocrio,? h4anager (TM)
+
Cacite Atorroger (CM)
=
Se/>ad?der I (SC)I
Data hfa,o,ragerDotobose (DB)
Recovery illo,ioger (RM)
Gambar
1Komponen sistem basis data terpusat (Bernstein
et al. 1987).
(DM)
11.3. Transaksi
Menurut Bernstein
et a1.(1987)
transaksi dalaln basis data merupakan eksekusi
dari satu atau lebih program untuk mengakses atau melakukan perubahan basis
data, termasuk di dalamnya operasi basis data
(readswrite)
dan operasi transaksi
(start, conznzit, abort).
Menurut Connoly dan Beg (2002) suatu transaksi memiliki
empat karakteristik yaitu
:1.
Atornic
Jika operasi dari transaksi dalam basis data berhasil dieksekusi semuanya,
permanen, tetapi sebaliknya bila terdapat kegagalan pada salah satu
operasi yang terjadi, lnaka semua perubahan yang ada pada basis data akan
dibatalkan.
2. Consistensy
Transaksi yang telah dilakukan, harus menjaga basis data tetap dalaln
kondisi konsisten.
3.
Independency
Setiap transaksi harus bersifat
independent
dan tidak boleh saling
mempengaruhi.
4. Durability
Perubahan yang berhasil dilakukan oleh sebuah transaksi harus dapat
disi~npan
secara permanen dalam basis data.
Empat Karakteristik tersebut disingkat dengan ACID
11.4. Serializabilily
Menurut Bernstein
er al.
(I987), ketika dua atau lebih transaksi yang
dieksekusi secara
coiiczrrrent,
maka dapat mengakibatkan transaksi satu
mernpengaruhi transaksi lainnya. Hal ini dapat menimbulkan basis data tidak
konsisten.
Salah sat11 cara untuk menghindari ha1 tersebut di atas, maka transaksi-
transaksi tersebut harus dieksekusi setara dengan serial. Sebuah eksekusi
dikatakan serial, jika untuk setiap transaksi, seluruh operasi dari transaksi yang
sama, dieksekusi sebelum operasi dari transaksi yang lain. Dalam pandangan
pengguna
(user)
eksekusi serial dipandang sebagai operasi transaksi yang diproses
oleh
DBS
secara
aton~ic.
Proses eksekusi dikatakan
serializable
apabila
menghasilkan keluaran yang salna dan mempunyai efek yang sama pada basis
data, jika
transaksi-transaksi-tersebut dieksekusi secara serial. Gambar 2 di bawah
ini, memperlihatkan contoh eksekusi transaksi, yang dilakukan secara serial.
Gambar
3
memperIihatkan contoh eksekusi transaksi yang dilakukan secara
serializable.
Dari Galnbar
2,
terlihat bahwa pada eksekusi serial, transaksi
dieksekusi satu per satu. Dengan de~nikian
transaksi tersebut tidak akan tumpang
akhir seperti pada eksekusi yang dilakukan secara serial walaupun transkasi
T,
dan
T2dieksekusi secara bersalnaan (concurrent)
Gambar 2 Contoh eksekusi transaksi setara serial.
Garnbar
3
Contoh eksekusi transaksi se.cara serializable
Concurrency
control
(CC)
rnerupakan
suatu
aktivitas
untuk
mengkoordinasikan proses-proses dala~n
mengakses atau melakukan perubahan
pada basis data yang beroperasi secara bersamaan (Bernstein el 01.
1987). Ozsu
optinzistic.
Pada
optir~zisfic
transaksi-transaksi yang datang dapat langsung
diproses tanpa harus menunggu validasi terlebil~
dahulu, yang mempunyai urutan
operasinya adalah
read, conrptcte, validate, write. Padapessinzistic
setiap transaksi
yang akan melakukan akses basis data harus melalui proses validasi terlebih
dahulu, sehingga urutan operasinya adalah
validate, read, conzpute,
dan
write.
11.6.
Two Plzuse Locking
(2PL)
Two Plrusc Locking
(2PL)
merupakan jenis
CC
yang
pessi?~zistic.
Pada
CC
jenis
irli mekanisme perolehan
lock
dan pelepasan
lock (unlock)
untuk suatu item
data dilakukan dalam dua tahap yaitu
:1.
Growing phase
:Suatu transaksi boleh mendapatkan
lock
tetapi tidak
boleh rnelepaskan
lock
yang telah diperoleh.
2. Shringking phase
:Suatu transaksi boleh melepas
lock
tetapi tidak
diperbolehkan rnelakukan permintaan
lock
baru
Pada saat permulaan eksekusi, suatu transaksi berada dalam
growing phase
Tetapi pada saat transaksi mulai melepas
lock,
maka transaksi tersebut berada
dalam
shringkingphase.
Terdapat dua macam modus
lock
yaitu
:1.
Shared lock (read lock)
:lock
yang diberikan pada transaksi yang
melakukan operasi readterhadap item data dalam basis data.
2.
Exclusive lock (write lock)
:lock
yang diberikan pada transaksi yang
melakukan operasi
write
terhadap item data dalam basis data.
Dua modus
lock
tersebut kompatibel apabila dua atau lebih transaksi bisa
mendapatkan
lock
dari item data yang sama dalam waktu yang bersamaan. Jika
modus
lock
yang diinginkan oleh suatu transaksi tidak kompatibel maka transaksi
tersebut harus menunggu sampai
lock
tersebut dilepas. Tabel
1 di bawah ini
mernperlihatkan kompatibilitas setiap modus
lock
8
11.7. Strict Two Pliuse Loclritzg
(Strict
2PL)
Strict
2PL
merupakan
CC
yang menggunakan mekanisme
lock,
yang banyak
dipakai pada produk komersial. Menurut Elmasri dan Navathe
(2000),
pada
mekanisme
CC
menggunakan cara ini, suatu transaksi selama eksekusi akan
nlelakukan permintaan
lock
suatu item data; dan mengakses atau memodifikasi
data. Hal ini dilakukan berulang-ulang sampai akses atau modifikasi suatu item
data selesai dilakukan pada suatu transaksi.
Pada akhir eksekusi, transaksi
melepas selnua
lock
untuk semua item data secara bersamaan. Grafik Strict
2PL
diperlihatkan pada Gambar 4. Dari Gambar 4 dapat dijelaskan bahwa
release
adalah pelepasan
lock
untuk suatu item data,
locking
adalah permintaan
lock
untuk
suatu item data,
execution
adalah operasi pada basis data
(read
atau
write)
Locking
4
Gambar 4 Grafik Strict
2PL
(Elmasri
&Navathe
2000).
Jika suatu transaksi tidak mendapatkan
lock
suatu item data, pada saat permintaan
lock,
maka transaksi tersebut akan menunggu
(blocked)
sampai item data tersebut
bebas dari
lock.
Gambar 5 memperlihatkan eksekusi transaksi menggunakan
CC
ini. Dari
Gambar tersebut dapat dijelaskan bahwa transaksi
TI
akan melepas semua
Iock
setelah eksekusi operasi dari transaksi telah diselesaikan semua. Selama
lock
suatu item data belum dilepas oleh
TI
maka apabila
Tz
membutuhkan
Iock
suatu
item data, harus menunggu. Pada Strict
2PL
bisa terjadi
deadlock,
karena suatu
transaksi masih memegang
lock
suatu item data, setelah proses modifikasi telah
Lock (A) Read (A)
- .~
rr'?;le (A)
rvr;re (B) Unlock (A)
U!rloc!@)
Lock (C) Read(C) C:=C+2
IWire (C)
Lock(A) R#od/A) A:=A+Z
[image:23.544.173.384.59.222.2]r m e (A) Unlock (C) U,ilock(A)
Gambar
5Contoh eksekusi transaksi pada
Strict 2PL.
Wuklu
r,
T:I
Lock (A)Lock (8)
Read (A)
Read (B) A:=A+lOO
B:=B+lOO
r%.;1e (4
IWire (B) Lock (B) D i b l a k o l e h T:
Lock (A) Diblak oleln T,
Gambar
6
Contoh
deadlock
pada
Strict 2PL.
Dari Gambar
6
dapat dijelaskan bahwa, transaksi
T,
dan transaksi
T 2tidak
dapat diproses, karena masing-masing saling menunggu salah satu dari dua
transaksi tersebut untuk melepas
lock.
Dalam situasi seperti ini salah satu dari dua
transaksi yang ada
(TI
atau
T2
)harus dipaksa untuk melepas
lock.
Jika
T,
yang
melepas
lock
maka transaksi ini harus melakukan
roll-back
dan memulai operasi
transaksi baru.
11.8.
Read-cor~mzit Order Concurrericy Coriirol
(ROCC)
ROCC
merupakan jenis
CC
yang
optitnistic.
Pada
ROCC,
suatu transaksi
boleh mengiri~n
lebih dari satu
access reguest message
( A R M )
yang berisi satu
10
baru yang berhubungan dengan inforinasi dari
request n~essage
tersebut, akan
dibangkitkan dalam
RC-quezce.
RC-qtrezre
mempunyai elemen yang terdiri dari
tujuhfield
yaitu
:Tid, validated
(V),
conzmit (C), restart (R), rend, write,
dan
next,
yang diperlihatkan pada
Gambar 7.
Tid
berisi
id
dari transaksi.
Read
berisi nilai itein data yang dibaca.
Write
berisi nilai itein data yang ditulis.
ValidatedJeld
bernilai satu jika suatu
transaksi tidak memerlukan validasi atau telah sukses dari proses validasi, dan
bernilai 0 jika suatu transaksi inemerlukan proses validasi atau belum dilakukan
validasi. Jika
cortznzitjield
bernilai
1,
mengindikasikan bahwa
request message
tersebut bertipe
coi~zmit,
dan bernilai 0 jika
reqzcest rizessage
tersebut bukan
bertipe
conzi1tit. Restart Jeld
akan bernilai
1 ,
jika transaksi tersebut merupakan
transaksi yang mengalami
restart,
dan bernilai 0 jika transaksi tersebut bukan atau
belum mengalami
restart. Nextpointer
akan menunjuk ke eletnen berikutnya yang
merepresentasikan bahwa elemen tersebut datang sebelumnya.
Pointer
pada-
elemen yang datang pertama kali di set ke
NULL. RC-quezre
adalah struktur data
yang digunakan oleh
ROCC
untuk melakukan validasi.
I ~ i d
IV
IC
k
keuds I ~ r i t e s
1
Next
I
Ga~nbar
7
Format elemen
RC-quezte
(Shi
&Perrizo 2004).
11.8.1.
Algoritma validasi
intervenitzg
Proses validasi pada algoritma ROCC dimulai ketika ada
request message
yang datang bertipe
conznzit.
Proses penelusuran untuk mencari elemen yang
operasinya konflik pada
queue,
dimulai dari elemen
read
pertarna dari transaksi
yang sedang dilakukan validasi
("First'?
yang dibandingkan dengan elernen lain
yang terletak diantara
"First"
sampai elemen dari transaksi yang sama berikutnya
first-down reached element).
Apabila penelusuran dari elemen
"First"
tidak menemukan operasi elemen
yang konflik
(read-write, write-read, write-write),
sampai diternukanfilst-down
reached element,
maka
"First"
akan digabungkan dengan
first-down reached
I
I
Jikafirst-down reached elen~ent
yang ditemukan adalah elemen co~nt~zit
dari
transaksi yang salna, illaka proses validasi dianggap sukses. Tetapi apabila yang
ditemukan bukan elemen cotiltt~it dari transaksi yang sama, maka proses
penelusuran dilakukan terus untuk inenemukan elemen yang operasinya konflik
sampai ditetnukanfirst-down reached elenlent berikutnya.
Apabila penelusuran dari elemen "First" menemukan operasi elelnen yang
konflik, ~ n a k a "First" dipindahkan ke posisi sebelum elemen dari transaksi lain
yang konflik, kemudian "First" yang asli akan dihapus dari RC-queue.
Proses penelusuran selanjutnya dimulai dari elemen comtnit, untuk mencari
elemen dari transaksi lain yang operasinya konflik dengan elemen conznzit
("Second'? sampai ditemukan elemen dari transaksi yang sama @-st-up reached
elernent). Apabila pada saat penelusuran dari "Second" tidak inenemukan elemen
yang konflik sampai ditemukanfirst-zrp reached element, maka "Second" akan
digabungkan dengan first-tip reached elentent. Gabungan kedua elemen tersebut
dianggap sabagai "Second" yang baru. Apabilafirst-up reached eletneprt adalah
"First" maka proses validasi dianggap sukses. Tetapi jika bukan "First", maka
"Second' akan dibandingkan terus sampai menemukanfirst-up reached elernent
berikutnya. Apabila pada saat penelusuran ditemukan operasi elemen yang konflik
maka proses validasi dianggap gagal.
Jika suatu transaksi gagal dalam proses validasi, maka transaksi tersebut akan
dilakukan restart. Scheduler akan menghapus semua elemen dari transaksi
tersebut. Setelah itu akan dibangkitkan sebuah restart eletnent dan menempatkan
di dalam RC-qrtezce. Restart elerttent terdiri dari seinua item data yang akan dibaca
(read) dan semua item data yang akan diubah (write) oleh transaksi yang
mengalami kegagalan dalam proses validasi.
Pseudocode algoritma validasi intervening pada
ROCC,
diuraikan dalam
penjelasan di bawah ini (Shi
&Perrizo 2004). Sebagai inisial "First"
=NULL,
dan"Second"
=NULL.
Algoritma tersebut akan dieksekusi apabila request
niessage yang datang bertipe commit. Setelah pseztdocode algoritma validasi
intervening, di bawah algoritma tersebut, diilustrasikan implementasinya pada
RC-queue yang diperlihatkan pada Gambar
8.
Ilustrasi implementasi algoritma
karena pada saat penelusuran ditemukan operasi elemen yang konflik baik dari
elemen
"First"
maupun dari elemen
conzntit.
"First"
=XULL; "Second" =NULL;
Locate the transaction'sfirst read eleinent in the RC-quezre;
Iffnot fotmd, return validated =true;
"First"
=the first read ele~lient;
While
(I)
{
Coinpare "First" with aN the elenzents of other transaction behind it until it
reached all elenzent of the sanie transaction first-down-reached eleinent);
If (There is no eleilzent conflict) //inoving doion to look for upper side
conflict
{
Merge the "First" element with the first-down-reached eleniet;
Rei~tove the "First" elenzent front the RC-Queue;
I f f
Thejirst-down-reached elentent is the coinniit elentent)
Return validated
=true;
Else "First"
=the
first-do~vn-reached-eletnent;
J
Else
i/There is uper-sided-conflict;
.{
Insert "First" into the RC-queue right before the conflicting element;
Remove the original "First"fi.0111
the RC-qzteue;
"Second"
=Collznzit element;
While
(I)
//i~zoving up to look for the lower-sided conflict;
{Co~npare "Second" with all the elenzent of other trunsactions before it
zrntil it reaches an ele~i~ent
of the saine transaction
first-trp-reached elenzent);
If(there is no eleinent conflict)
{Merge the "Second" elelllent to the first-up-reached elenzent;
Renzove tile "Secoiid"elen~ent
from the RC-queue;
I f (the first-up-reched elelltent is the first)
Return validated=trzre;
Else "Second"
=first-up-reached eleilzent;
I
Else //there is also Lower-sided-conflict, the validation fails.
{Remove all elentents of the transaction front the RC-queue
Retzrrn validated= false;
I
Pada Gambar
8
diperlihatkan keadaan
RC-queue
dengan empat transaksi yang
terdapat pada
quezre.
Transaksi yang terdapat pada urutan pertama adalah
TI
yang
mengirim
readreqzrest
untuk melnbaca objekx,
y,z,
(rib), rib), rie)).
Kemudian
read
untuk item data
v(rz(v)),
operasi
read
untuk item data
z i(r2(u)),
dan
operasi
write
untuk item data
x'vz(x)),
berikutnya adalah transaksi
T3
juga telah
sukses dilakukan validasi dengan operasi
read
ontuk item data
z (r3(z)),
operasi
read
untuk item data
Z L(r3(u)),
dan operasi
write
untuk item data v
(w3(*.
Akhirnya
TI
mengirirn
cottititit request
untuk mengubah item data
zyaitu
wIk).
Langkah melakukan validasi pada
RC-queue
Gambar
8,
dimulai dari bagian atas
(front)
yaitu dengan cara mencari transaksi yang operasi elemennya konflik
dengan
"First".
Penelusuran dari
"First"
menemukan elemen dari transaksi lain
yang operasinya konflik, yaitu operasi
write
item data
x,
dari transaksi
T2 (wz(x)).
Kemudian proses validasi dilanjutkan dari elemen
commit. "Second"
adalah
elemen
conzniit. "Second"
dibandingkan dengan elemen
-dari transaksi lain.
Penelusuran dari
"Second"
menemukan operasi item data yang konflik, yaitu
operasi
read
item data
zdari transaksi
T3 (r&)),
sehingga proses validasi untuk
[image:27.539.74.447.24.754.2]transaksi
TI padaiiC-queue
Gambar
8
dinyatakan gaga].
Gambar
8
RC-queue
pada
ROCC.
11.8.2.
Komponen ROCC
ROCC
diimple~nentasikan n~enggunakan tiga komponen, yaitu
client-side
procedure, schedztler-side procedure,
dan
data-ittanager side procedure
(Shi
&Perrizo 2004). Pada Gambar
9
ditunjukkan ketiga komponen tersebut Dari
Gambar
9,
dapat dijelaskan bahwa
pengguna melakukan transaksi melalui
transaction manager
( T M ) ,
kemudian diteruskan ke
scheduler
(SC)
untuk
dilakukan penjadwalan dalam mengakses basis data. Apabila berhasil dalam
akan diteruskan ke
datanlanager
(DM)
untuk membacafmengubah data yang
dimaksud.
Tnnractian Manager
SC-Side Procedure
DM-Side Procedure
Database (DB)
111. M E T O D E PENELITIAN
111.1.
Metode Perbaikan Algoritma R O C C
Bernstein
et al.
(1987)
menjelaskan cara untuk mengenali himpunan transaksi
yang dieksekusi
(history)
yang
serializable.
Jika sebuah
history
H
dengan
transaksi
T={T/,
Tz,
...
T,,}
maka
serialization graph
(SG) dari
history
H
(SG(H))
adalah
directed graph
dengan
node
adalah transaksi-transaksi dalam
T,
yang
sudah melakukan
coiiznzit
dalam
H.
Edge
adalah
i;+
I;.
jika salah satu dari
operasi-operasi
i;konflik dengan salah satu dari operasi-operasi
2;
dalam
H,
dan
Ti
dieksekusi lebih awal dari
q.
Sebuah
history
H
adalah
serializable,
jika SG(H)
adalah
acyclic.
Modifikasi algoritma R O C C dilakukan dengan cara terlebih dahulu mernbuat
SG dari beberapa kondisi
RC-qzreue,
sehingga ditemukan keadaan dimana
t e r d a p t SG yang
acyclic
tetapi algoritma validasi
intervening
~nelakukan
restart.
111.2. Metode Evaluasi Kinerja
Penelitian untuk mengukur kinerja ROCC, ROCCM, dan Strict 2PL
dilakukan dengan si~iiulasi yang
berbasis pada Shi dan Perrizo (2004).
Pelaksanaan simulasi dilakukan dengan menggunakan simulator. Simulator
dibangun dengan bahasa pemrogra~nan C
Builder Version 6.0
dengan cara
~nelakukan modifikasi program simulator dari penelitian sebelumnya yang
dilakukan oleh Shi dan Perrizo (2004). Spesifikasi komputer yang digunakan
pada pelaksanaan simulasi, menggunakan sistem operasi
Windows MilIeniurn,
lnemori
=512
Mlyte,
prosessor
=Intel Pentiur~z 4 2.66 GHz,
serta hardisk
=40
Gbyte.
Silnulasi yang dilakukan dengan parameter-parameter input yang sama pada
ketiga algoritma tersebut. Paremeter-parameter simulasi diperlihatkan pada Tabel
2. Pernberian nilai parameter input untuk simulasi ini, tidak berdasarkan pada data
sesungguhnya, tetapi merupakan asumsi-asumsi yang diambil dari penelitian
Tabel 2. Parameter-parameter input simulasi
~nisialisasi
transaksi baru dari suatu terminal.
Hasil simulasi yang tampil adalah
tlzrozcghput, response tinie,
dan
restart ratio
untuk ketiga algoritma yang dievaluasi.
Throughput
dalam ha1 ini adalah jumlah
transaksi yang dapat diselesaikan per satuan waktu.
Restart ratio
adalah jumlah
rata-rata transaksi yang mengalami
restart
per satuan waktu.
Respon tittle
adalah
waktu di antara ketika sebuah terminal mengirim sebuah transaksi baru dan ketika
hasil transaksi baru tersebut dike~nbalikan
ke terminal. Hasil simulasi diuji dengan
uji
t-stzrdent
menggunakan selang kepercayaan
(conJidence interval)
95%
(Law
&IV. HASIL DAN
PEMBAHASAN
IV.l.
Algoritlna R O C C M
Teorema yang diketnukaltan oleh Shi dan Perrizo
(2004), mengungkapkan
bahwa R O C C menghasilkan eksekusi transaksi yang
serializable.
Karena jika
terdapat eksekusi yang tidak
serializable,
maka ada
cycle
dalam
serialization
graph
(SG) dalam
RC-queue.
Sebagai asumsi, terdapat sebuah
cycle
dala~n
RC-
qt~ezle
yang terdiri dari
TI
3Tz
...
T,,
+TI,
~ n a k a
dalam transaksi-transaksi tersebut,
terdapat konflik antara
TI
darl
T2,
sel-ta terdapat konflik antara
T,
dan
T,.
Algorit~na validasi
illtel-vening
yang terdapat pada ROCC, akan ~nembatalkan
transaksi yang lne~npunyai dua elemen yang keduatlya konflik dengan elemen
transaksi lain yang terletak di antara elelnen yang konflik tersebut. Dengall
demikian,
cycle
aka11 dihentikan, karena transaksi yang dibatalkan akan dilakukan
restart.
Ga~nbar
10
RC-qztelre
dengan eksekusi
serializable
pada R O C C
Garnbar
1 1Acyclic
SG,
Dari hasil penelitian yang telah dilakukan, terdapat keadaan
RC-quetre
dengan
eksekusi
serializable,
tetapi terdapat transaksi yang Inengalami
restart
pada saat
18
10. Pada Gambar 10, transaksi yang datang pertama kali adalah
TI
yang aka11
~nengakses item data
x
(rl')),
item data y
(r,(y),
dan item data
z
(rl(z,).
Selanjutnya setelah transaksi
TI
terdapat transaksi
fi
yang telah dilakukan validasi
dimana transaksi
TZ
terselmt melakukan perubahan nilai item data
x
yaitu
wz6).
Setelah transaksi
T2
terdapat transaksi
T3
yang hanya ingin mengakses item datay
(r30).
Akhirnya transkasi
TI
akan melakukan perubahan nilai item data
zhv&)).
Proses validasi dimulai dari elemen
read
pertama kali untuk transaksi
TI
("First'?,
yang menemukan operasi elenien yang konflik yaitu item data
x
dari
operasi
w&)
pada transaksi
T2.
Kerena ditemukan elemen yang konflik dengan
"First"
dari transaksi
Tz,
maka proses validasi selanjutnya dimulai dari bagian
bawah dengan membandingkan elemen
coniniit ("Second'?
dari transaksi
TI
dengan transaksi sebelumnya. Penelusuran dari
"Second",
menemukan elemen
yang konflik, yaitu operasi
read
untuk item data
z,dari transaksi
T3 (I-3(~)).
Pada
kondisi ini transaksi
TI
mengalami
restart,
padahal eksekusi transaksi adalah
merupakan eksekusi yang
serializable.
SG pada Gambar 11 merupakan ilustrasi dari eksekusi transaksi untuk
RC-
queue
pada Gambar 10. Dari Gambar 11 tersebut dapat diketahui bahwa tidak
terdapat
cycle
dalam SG tersebut, yang menunjukkan bahwa eksekusi
lransaksinya bersifat
serializable.
Perbaikan algoritma
ROCC
menjadi
ROCCM,
dilakukan dengan mengubah
cara validasi yang dilakukan oleh algoritma validasi
intervening.
Proses validasi
pada algoritma
ROCCM
akan diuraikan dalam penjelasan di bawah ini.
"First"
adalah elemen operasi
read
dari transaksi yang melakukan
conimit.
"Conibine"
adalah kumpulan elemen yang operasinya konflik dengan elemen
coninzit ("Second'y
maupun operasinya konflik dengan elemen
"Combine
"sebelumnya. Sebagai inisialisasi awal
"Cornbine"
=(1.
Langkah-langkah untuk
melakukan validasi setelah suahi transaksi mengirimkan
coniniit request,
pada
ROCCM
selengkapnya adalah sebagai berikut
:1.
Bandingkan
"First"
dengan elemen dari transaksi lain yang terdapat di
antara
"First"
sampai elemen
contniit.
Bila pada saat penelusuran
19
elentet~l)
maka gabungkan elemen
"Firsi"
ke dalam elemen transaksi
yang sama berikutnya. Kemudian bandingkan
"First"
hasil gabungan
tersebut, dengan elemen dari transaksi lain yang terdapat di antara
"First"
sampai elemen
coninzit.
Proses penelusuran dilakukan terus untuk
menemukan elemen yang konflik atau elemen
read
berikutnya. Bila
transaksi berikutnya yang ditemukan, adalab elemen
cor~zn~it
dari transaksi
yang sama, dan tidak terdapat konflik maka validasi dinyatakan sukses.
2.
Jika
"First"
konflik dengan elemen dari transaksi lain, pindahkan elemen
"First"
ke posisi transaksi sebeluln elemen dari transaksi lain yang
konflik. Hapus elemen
"First"
yang asli dari
RC-qzceue.
3.
Bandingkan
"Second"
atau
"Con~bine
"dengan elemen dari transaksi lain
yang terdapat di antara
"Second"
sampai ditemukan elemen dari transaksi
yang sama
("First-up reached elenzent'y.
Setiap elemen yang konflik,
lakukan
insert
ke
"Con~bine
".
4.
Bandingkan
"Conzbine
"dengan
"First-zip reached element"
Jika terdapat
konflik maka validasi dinyatakan gaga]. Jika tidak terdapat konflik
lakukan pengecekan apakah
"First-up reached elenzenl"
adalah
"First",
jika merupakan
"First
maka validasi dinyatakan sukses, tetapi jika bukan
elemen
"First"
lanjutkan langkah
5.
5.
Gabungkan
"SeconG'
dengan
"First-up reached element"
hapus
"Second"
asli dari
RC-quezre.
Lanjutkan langkah
3.
Pseudocode
algoritma validasi pada
ROCCM
selengkapnya terdapat pada
urian di bawah ini. Pada algoritma validasi
ROCCM,
tersebut, proses
penelusuran dari elemen
"First"
sama dengan aigoritma validasi pada
ROCC.
Perbedaannya terdapat pada proses penelusuran dari elemen
con~njit
yaitu terdapat
proses membandingkan antara elemen
corlzn~it
atau elemen
"Combine"
dengan
elemen yang terdapat di antara elemen
commit
tersebut sarnpai ditemukan elemen
transaksi yang sama
rFirst-up reached elenlent'?.
Jika ditemukan elemen yang
konflik dengan elemen
conlmit
atau
"Combine"
maka elemen dari transaksi lain
yang terdapat konflik, akan dilakukan
insert
ke
"Conlbine
".
Kemudian dilakukan
20
konflik maka validasi dinyatakan gagal. Jika tidak terdapat konflik lakukan
pengecekan apakah
"First-zip reached element"adalah
"First",jika merupakan
"First"
maka validasi dinyatakan sukses, tetapi jika bukan elemen
"First",
maka"Second"
digabungkan dengan
"First-zip reached elentent" dunproses
penelusuran berjalan terus untuk menemukan elemen yang operasinya konflik
dengan
"Second"atau
"Con~bine",sampai ditemukan elemen dari transaksi yang
sama. Algoritma selengkapnya adalah sebagai berikut
:"First" = NULL; "Second" =NULL; "Conzbine "=NULL; Locate the transaction 'sfirst read element in the RC-queue; If(notfound) return validated =true..
"First" = the first read elentent; While (1)
J Conzpare "First" wifh all the elenzents ofother transaction behind it until it reached an elernent of the sanze transaction first-down-reached elenzent);
If(T1~ere is no elenzent conflict) //nzoving down to look for tipper side conflict {Merge the "First" elenzent with the first-down-reached elemet; .
Rernove the "First" elenzent from the RC-Q~ceue;
If(Tlzefirst-down-reached element is the commit elenzent) Return validated = true;
Else "First" = the first-down-reached-elert~ent;
I
Else // There is liper-sided-conflict;
{Insert "First" into the RC-queue right before the conflicting element; Rmnove the original "First"fr0rn the RC-queue;
"Second" = Conzmit elenzent;
While (I) /hzzoving up to look for the lower-sided conflict;
{Con~pare "Second" wirfz all the elenlent of other transactions before it until it reaches an elenzent of the same transaction first-lip-reached element); Insert elerncnt conflict with "Second" or Contbine" to "Cotnbine;
{Conzpare first-up-reachen eletizcnt" with "Combirze"; If(There is no elernent co~zflict)
{Merge the "Second" element ~vith the first-up-reached element; Remove the "Second" elementfronz the RC-qzieue;
I f the first-up-reached elenzent is the "First'y Return validated =hue;
Else "Second" = the first-up-reached elernent;
I
Else //there is also Lo)ver-sided-conflict, the validation fails. {Remove all elenzents of the transaction~om the RC-queue
Return validated= false;
Pada algoritma validasi
ROCCM
di atas, yang tercetak tebal merupakan
bagian modifikasi dari algoritma sebelumnya.
Ilustrasi inlplementasi algorit~na
ROCCM,
untuk beberapa kondisi
RC-queue
diperlihatkan pada Gambar 12.a, 12.b, dan 12.c. Pada Gambar 12.a diperlihatkan
keadaan
RC-queue
dengan empat transaksi yang terdapat pada
queue.
Transaksi
yang terdapat pada urutan pertama adalah
TI
dengan operasi
rl'),
r,(yl, r&).
Kemudian disusul dengan transaksi
T2
yang telah dilakukan validasi dengan
operasi-operasi
r2(w), r2(u),
dan
wz(x),
berikutnya adalah transaksi
T3
juga telah
sukses dilakukan validasi dengan operasi-operasi
r&), I&), w ~ ( v ) .
(c)
Gambar 12
RC-queue
pada algoritma
ROCCM:
(a) hasil validasi tidak
restart,
[image:35.532.53.454.41.731.2]Akhirnya TI mengirim col~znzit request untuk mengubah item data
zyaitu
wle). Langkah melakukan validasi pada RC-quezie Gambar 12.a, dimulai dari
bagian atas pant) yaitu dengan cara mencari transaksi yang operasi elemennya
konflik dengan "First". Penelusuran dari
"First"menemukan elemen dari
transaksi lain yang operasinya konflik yaitu operasi write item data
x,
dari
transaksi T2 (102()1). Kemudian proses validasi dilanjutkan dari bagian bawah.
"Second" adalah elemen conmit. "Second" dibandingkan dengan elemen dari
transaksi lain, yang menemukan operasi item data yang konflik, yaitu operasi read
item data z dari transaksi T3, sehingga elemen yang disalin ke "Combine" adalah
item data dari operasi readtransaksi T3 yaitu 2,s dan item data pada operasi write
dari transaksi T3 yaitu v, sehingga elemen-elemen serta operasinya yang terdapat
pada "Con7bilie" adalah r3(z),
r3(s),w3(v).
Penelusuran berikutnya metnbandingkan "Second" dengan transaksi di
atasnya, karena tidak ada operasi elemen yang konflik dengan "Second" maka
kemudian dibandingkan dengan "Combine
"yang juga tidak menemukan konflik.
Karena tidak ada operasi elelnen yang konflik berikutnya yang ditemukan, sampai
ditemukan elemen "First", maka akhirnya "Cornbine" dibandingkan dengan
"First" yang juga tidak rnenemukan konflik sehingga proses validasi untuk
keadaan RC-qrtezie Gambar 12.a dinyatakan sukses, dengan
T/
dapat melakukan
operasi perubahan item data z.
Hasil validasi yang dilakukan pada RC-queue Gambar 12.b, berhasil
menemukan konflik dengan "First" untuk transaksi TI, yaitu operasi item data
x(M~(x))
dari transaksi TI. Selanjutnya proses validasi dari elemen cornnzit untuk
transaksi TI, berhasil menemukan konflik yaitu operasi item data y (w4(y)) dari
transaksi T4, sehingga 1v4(yl disalin ke "Conzbine". Terakhir "Combine"
dibandingkan dengan "First" yang berhasil menemukan konflik yaitu operasi
item data y (,vl(y), yang konflik dengan r&),
sehingga transaksi TI mengalami
restart.
Proses validasi pada RC-queue Gambar 12.c dimulai dari "Firsf" yang
dibandingkan dengan elemen dari transaksi lain yang terdapat di antara "First"
data
x (rz(x))
dari transaksi
T2.
Ke~nudian proses validasi dilanjutkan dari
bawah dengan lnelnbandingkan
"Second"
dengan transaksi lain, yang dalam ha1
ini mene~nukan
konflik yaitu operasi
read
item data
z(r&)
dari transaksi
T4,
maka seluruh elemen pada transaksi
T4,
yaitu elemen
read z (r4(4))
dan elemen
write
u'v4(u))
akan disalin dan digabungkan ke
"Combine".
Penelusuran berikutnya membandingkan
"Second"
dengan transaksi di
atasnya, dalam ha1 ini karena tidak ada elemen yang konflik dengan
"Second"
kemudian operasi elemen transaksi tersebut dibandingkan dengan
"Combine"
yang menemukan konflik, yaitu operasi
read
item data
trpada transaksi
T3 (r3(u)).
Elemen-elemen dari transaksi tersebut (elemen
read u ( r 3 0 )
dan elemen
write
(w3(1v)))
disalin dan digabungkan ke dalam
"Coinbine
".
Penelusuran terhadap elemen transaksi berikutnya tidak menemukan konflik
dengan
"Second"
tetapi mene~nukan operasi elemen yang konflik dengan
"Coiitbine!'
yaitu item data
ivdari operasi
rzfiv)
transaksi
T2,
sehingga dalam ha1
ini elemen
r2(1v), r2(v), dun wz6)
disalin dan digabungkan ke
"Cornbine"
sehingga elemen
"Combine"
~nenjadi
(rdfir), w4(z); r3(u), w3(w); r2(w), rz(v),
1v2($)
Akhirnya
"First"
dibandingkan dengan
"Cornbine"
yang menemukan
konflik yaitu operasi item data
x (w2(x)
konflik dengan
UJ/(X)),
sehingga transaksi
TI
pada
RC-queue
Ga~nbar
12.c
mengalami
restart.
IV.2.
Pelaksanaan Simulasi
IV.2.1.
Asurnsi-asumsi simulasi
Simulator yang digunakan untuk mengukur kinerja
CC
tersebut, menggunakan
model antrian tertutup pada suatu sistem basis data terpusat, seperti diperlihatkan
pada Gambar
13
dan Gambar
14.
Pada simulator terdapat sejumlah terminal,
untuk membangkitkan transaksi. Selanjutnya terdapat batasan transaksi yang aktif
pada suatu saat di dalam sistem
(ntpl).
Apabila transaksi yang dibangkitkan oleh
sejumlah terminal melebihi batasan transaksi yang diijinkan oleh sistem (melebihi
nlpl),
maka transaksi tersebut diletakkan dalam
ready queue
untuk menunggu
transaksi dalam sistem selesai atau ada yang dilakukan
abort.
Sebaliknya apabila
transaksi yang aktif dalam sistem tidak melebihi
mpl,
maka transaksi yang
24
membuat permintaan operasi akses basis data melalui
CC.
Jika 1010s dari
operasi yang dilakukan oleh
CC,
selanjutnya transaksi tersebut mengakses data.
Jika data tersebut ada di
b~rJfer
niaka eksekusi dilanjutkan ke CPU. Tetapi jika
data tersebut tidak terdapat di
bzrJfer
maka eksekusi akan dilewatkan ke disk untuk
mengakses data untuk seterusnya dilanjutkan ke CPU. Untuk mengakses
disk
serta diproses pada
cpu
harus melalui antrian di disk serta CPU yaitu
disk-queue
dan
cpu- qzleue.
Pada simulasi diasumsikan juga, bahwa sebuah transaksi melakukan operasi
read
terlebih dahulu sebelum melaksanakan operasi
write.
Diasumsikan juga
jaringan yang digunakan adalah jaringan
Local Area Nehvork
(LAN)
dalam
keadaan handal pada saat transmisi data dari terminal ke server. Jalur
think
nlemberikan nilai
random delay
pada waktu mengakses item data. Pada
Strict
2PL,
jika hasil dari
CC
memutuskan bahwa suatu transaksi harus di
block
maka
.transaksi tersebut dimasukkan dalam
block qzlelre
sampai permintaan akses data
dapat diproses. Jika
CC
menetapkan untuk melakukan
restart
suatu transaksi,
maka transaksi tersebut akan dilakukan
restart
dan selanjutnya dimasukkan ke
dalam
ready queue.
Jika suatu transaksi telah kornplit (selesai) maka
CC
akan
memberikan
co~i~nzit
succes Itlessage
ke terminal.
IV.2.2. Model
Simulasi
Pada simulator terdapat dua model
logical queuing
yaitu yang pertama model
antrian untuk
ROCCM
dan
ROCC
yang diambil dari penelitian sebelumnya (Shi
&
Perrizo 2004), serta yang kedua model antrian untuk
Strict
2PL.
Gambar 13 di
bawah ini memperlihatkan model antrian yang pertama pada simulator.
Pada Gambar
13 diperlihatkan terdapat sejumlah terminal untuk
membangkitkan transaksi. Ketika suatu transaksi baru diinisialisasi, sistem akan
melewatkan transaksi pada
ready queue
untuk diteruskan ke
cc queue.
Transaksi
yang 1010s validasi akan dilanjutkan untuk mengakses data di
bzcfer
atau
disk.
Setelah mendapatkan data operasi transaksi diteruskan ke
cpu.
Setelah dieksekusi
oleh
cpu
terdapat pemberian nilai
int-think
dan
ext-think
Transaksi yang gagal
validasi akan dilakukan
restart
dan kembali masuk
ready queue.
Eksekusi
Gambar 13 Model
logical queuing
untuk
ROCCM
dan
ROCC
pada simulator
(Shi
&Perrizo 2004).
Gambar 14 memperlihatkan model antrian untuk
Strict
2PL pada simulator.
Model tersebut merupakan modifikasi dari model
logical qziezring
penelitian
sebelumnya dan ditambahkan dengan jalur transaksi yang mengalami
blocked
serta
blocked queue
untuk menampung transaksi yang mengalami
blocked.
Eksekusi antrian hampir sama dengan model antrian pada
ROCC
dan
ROCCM.
Perbedaannya pada model antrian
Strict
2PL
adalah terdapat
block queue
untuk
menalnpung transaksi yang mengalami
blocked
untuk kemudian diteruskan ke
cc
qzreue.
Parameter input
defaut
yang digunakan pada pelaksanaan simulasi
[image:39.541.75.465.66.725.2] [image:39.541.84.461.72.326.2]Gambar 14 Model
logical queuing
untuk Strict 2PL pada simulator
(modifikasi dari model Shi dan Perrizo (2004)).
Tabel 3 Nilai parameter input
default
pada pelaksanaan silnulasi
Nilai
1000
pages
10
pages
4
pages
0,25
I
ms
1
ms
3
5
800
0,s
35
ms
15
ms
[image:40.532.50.435.52.693.2] [image:40.532.65.433.53.290.2]27
IV.3.
Hasil Simulasi
Pelaksanaan simulasi dengan parameter input seperti pada Tabel 3,
dimaksudkan untuk mengetahui kinerja ketiga algoritma yang diuji, berdasarkan
nilai parameter daii penelitian sebelu~llnya
(Shi
&Perrizo 2004).
Hasil simulasi pada
fhrorighput
dapat dilihat pada Gambar 15.a serta Tabel 4.
Melalui Gambar 15.a tersebut, dapat diketahui bahwa
ROCCM
mempunyai
nilai yang lebih tinggi, bila dibandingkan dengan algoritma
ROCC
dan Strict
2PL.
Uji
t-student
pada
sainple
dengan derajat bebas
(d' =(n1+n2-2)
yang melniliki
2
. .
rata-rata
xdan
y,serta
variance s?
dan
sz
d~hitung
dengan persamaan di bawah
ini
:Pada pengujian dengan menggunakan derajat bebas 8
(5
+
5 -2) dan
95
%con$dence interval,
jika -1.86
<
t
<
1.86 maka perbedaan tidak nyata. Hasil
pengujian dengan uji
t-student
menunjukkan bahwa perbedaan
fhroughput
antara
ROCC
dan
ROCCM,
cukup nyata pada
tizpl
di atas 50 (Lampiran
3).
Dari
Gambar 15.a juga dapat diketahui bahwa
throz~gliprit
Strict
2PL
ada pada posisi
terendah.
Hasil simulasi pada
restart ratio,
dapat dilihat pada Gambar 15.b maupun
Tabel 4. Gambar 15.b memperlihatkan perbedaan
restart ratio
ketiga algoritma
yang diuji. Dari gambar tersebut, dapat diketahui bahwa
resturt ratio
ROCC
berada pada posisi tertinggi terutama pada
nip1
=200.
Gambar 15.c, memperlihatkan hasil simulasi dalam ha1
response time.
Melalui
gambar tersebut, dapat diketahui bahwa
response titile
antara
ROCCM
dan
ROCC,
secara umum ha~npir
sama pada berbagai
ii7pl.
Pada Tabel 4, ditunjukkan rekapitulasi kinerja algoritma pada
throughput,
restart ratio
dan
response tiiiie.
Pada tabel tersebut
T
adalah
throughput,
RR
adalah
response time,
dan RT adalah
restart ratio.
Melalui tabel tersebut, juga
28
nzpl
=10
me~npunyai
nilai yang kecil. Tetapi nilai-nilai tersebut akan selnakin
[image:42.532.55.463.42.563.2]jauh berbeda seiring dengan naiknya jumlah
mpl.
29
Tabel 4 Rekapitulasi hasil simulasi
IV.4.
Evalusi kinerja algoritma
Bargava
(1999)
mengemukakan bahwa salah satu cara untuk melakukan
evaluasi terhadap kinerja sebuah algoritma
CC
adalah dengan melakukan
evaluasi terhadap
throzrghptit, response tinie, dun restart ratio.
Dari hasil simulasi
yang ditampilkan pada eksperimen ini, dapat jelaskan bahwa algoritma
ROCCM
mempunyai
troughput
yang lebih tinggi. Sernentara itu
restart ratio
berada di
bawah
ROCC.
Selain itu
ROCCM
mempunyai
response tiwe
yang hampir sama
dengan
ROCC.
Throughput
ROCC
secara umurn berada tepat di bawah
ROCCM.
Sementara
itu
ROCC
mempunyai angka
restart ratio
yang lebih tinggi. Dari hasil penelitian
yang telah dilakukan dapat dikemukakan bahwa angka
response tirtze
ROCC
hampir sama dengan
ROCCM
yang mempunyai
response tittle
lebih cepat bila
dibandingkan dengan Strict
2PL.
V. KESIMPULAN DAN SARAN
V.1.
Kesi~npuIan
Melalui penelitian perbaikan dan evaluasi kinerja algorit~na
ROCC
dapat
disi~npulkan
:1.
Secara umum
throtrghput
ROCCM
lebih tinggi, bila dibandingkan
dengan
ROCC
dan Strict
2PL.
2. Restart ratio
ROCCM
lebih rendah dari
ROCC.
3.
Response time
ROCCM
tidak jauh berbeda dengan
ROCC.
4. Dengan ~nelakukan perbaikan algoritma
ROCC,
restart ratio
yang terjadi
akan berkurang sehingga lnenaikkan kinerja algoritma tersebut.
V.
2.
S a r a n
3
1
DAPTAR PUSTAKA
Bargava B. 1999. Concurrency Control in Database Systems. IEEE
Transaction
on Knowledge and Data Engineering
1 l(1): 3-1 6.
http
:l/citeseer.ist.psu.edulbhargava99concurrency.html.
[
28 Oktober 20051.
Bernstein PA, Hadzilacos
V,
Goodman N. 1987.
Concurrency Control and
Recovery in Database Systeirt.
New York: Addison-Wesley Publishing
Company. hlm. 25-37.
Connoly
T,
Begg C. 2002.
Database Systenl : A Practical Approach to
Design, Iittplernentation, and Managenlent.
New York
:Addison -Wesley
Publishing Company. him. 14-18.
Ellnasri
R,
Navathe S
B.
2000.
Fundarnental of Database Systems.
New York
:Addison -Wesley Publishing Company. hlm. 662-668.
Law AM, Kelton WD. 1991.
Sirritllation Modelling and Analysis.
Ed ke-2.
Singapore: Mc Graw Hill Inc. him. 289.
Ozsu
MT,
Valduriez P. 1999.
Principle of DistribzttedDatabase Systenzs,
Ed ke-2.
New Jersey: Prentice Hall
