Studi Kasus
Pembayaran SPP
di Universitas Pendidikan Indonesia sekarang sudah menggunakan sistem
autodebet. Dimana, akan ada penarikan otomatis dari saldo di rekening mahasiswa
sebesar jumlah SPP yang wajib dibayar pada tiap semester nya. Banyak mahasiswa
yang terkadang tidak memperhatikan kapan jadwal dimulainya penarikan otomatis
untuk pembayaran SPP tersebut, sehingga banyak pula mahasiswa yang sesaat kaget
melihat saldo rekening yang tiba-tiba menipis drastis. Dalam kasus ini, ada
seorang mahasiswa A yang ingin melakukan transfer ke rekening lain ketika
hendak belanja online. Saat di cek saldo tabungan, si mahasiswa masih memiliki
uang senilai Rp. 2.150.000. Si A ingin mentransfer uang ke rekening penjual
barang sebesar Rp.500.000. Namun, ketika A sedang melakukan proses transfer,
saat itu juga dimulainya jadwal autodebet untuk pembayaran SPP senilai Rp.
2.000.000, dan terambillah sudah uang tabungan senilai uang SPP yang harus
dibayar, sehingga saldo si A dalam tabungan hanya tinggal Rp. 150.000. Seperti
dikatakan di awal, banyak mahasiswa yang tidak memperhatikan kapan jadwal dimulainya
penarikan otomatis untuk pembayaran SPP, salah satunya adalah si A. Maka pada
saat si A sedang melakukan transaksi untuk belanja akan selalu gagal karna
jumlah yang akan ditransfer melebihi saldo dalam tabungan. Padahal dengan yakin
si A sudah cek saldo sebelum melakukan transaksi dan saldonya mencukupi untuk
transfer. Setelah atm card dikeluarkan dan dicoba kembali melakukan cek ulang
saldo, ternyata saldo si A sudah ter-autodebet untuk pembayaran SPP.
Materi yang terkait dalam studi
kasus di atas adalah tentang concurrency, khususnya pada sub pembahasan lock. Sebelum
memulai pembahasan dan penyelesaian kasus di atas, saya akan mencoba memberikan
sedikit penjelasan tentang materi concurrency untuk memudahkan dalam pembahasan
studi kasus ini.
Materi Bersangkutan
Banyak submateri
yang harus dibahas untuk concurrency, mulai dari permasalahan dalam
concurrency, locking, deadlock, isolation level, dan lain-lain. Disini akan
dibahas beberapa permasalshan dalam concurrency. DBMS yang sering kita gunakan
mengizinkan banyak transaksi pada saat bersamaan untuk mengakses data yang
sama. Pemakaian satu sumber secara bersama-sama pastinya akan menggganggu
jalannya transaksi, itulah yang dimaksud dengan concurrency. Oleh karna itu
kita membutuhkan Concurrency Control Mechanism agar transaksi tidak saling
mengganggu. Ada 3 (tiga) masalah dalam concurrency, ada lost update problem, uncommited
depedency problem dan inconsistent
analysis problem. Berikut adalah contoh dari ketiga permasalahan di atas:
Lost Update Problem, merupakan suatu
masalah yang timbul akibat dihiraukannya informasi pada saat ada update dari
user lain yang hampir bersamaan waktunya. Misalnya: ketika user 1 mengambil
data R, dan kemudian user 2 juga mengambil data R. Setelah user 2 mengambil
data, user 1 melakukan update data R dan di COMMIT. Ketika user 2 ingin
mengupdate data R, maka sebenarnya user 2 akan mengupdate data baru dari
updatetan user 1 bukan data yang awalnya sudah di ambil.
Uncommited Depedency Problem, ini
terjadi jika satu transaksi membaca hasil dari transaksi lainnya sebelum
transaksi kedua dinyatakan COMMIT.
Inconsisten Analysis Problem, Ketika
transaksi pertama membaca beberapa nilai, tetapi transaksi kedua melakukan
perubahan terhadap nilai tersebut, selama eksekusi transaksi pertama berlangsung.
Pada transaksi database, dikenal
istilah locking yang berfungsi untuk menjaga integritas data. Terdapat dua buah
metode locking yaitu :
- SHARED
LOCK (S-LOCK)
Jika
transaksi mendapat shared lock pada suatu data, transaksi tersebut hanya bisa
melakukan pembacaan.
- EXCLUSIVE
LOCK (X-LOCK)
Bagi
transaksi yang mendapat exclusive lock pada suatu data, transaksi tersebut
dapat melakukan perubahan dan pembacaan terhadap data tersebut.
Dengan kata
lain, aktifitas yang dapat dilakukan ketika mendapat lock adalah sebagai
berikut:
•
Jika transaksi A memegang Xlock pada sebuah
record, maka permintaan lock (X,S) pada record yang sama harus diabaikan.
•
Jika transaksi A memegang Slock pada record R
maka:
–
Permintaan Xlock trans. lain pada R ditolak
–
Permintaan Slock trans. lain pada R diterima
Untuk shared
lock, dapat dimiliki oleh beberapa transaksi dalam satu waktu, namun untuk
exclusive lock, hanya dapat dimiliki oleh satu transaksi pada satu waktu.
Pembahasan
Kasus
Pada kasus di atas, transaksi autodebet yang sedang berlangsung hanya
menggunakan metode shared lock. Sehingga ketika transaksi autodebet (penarikan
saldo) sedang berlangsung, nasabah masih bisa mengambil data / membaca saldo
pada waktu yang bersamaan melalui mesin atm. Namun data yang dibaca adalah data
sebelum transaksi di bank berakhir (sebelum commit autodebet). Sehingga si A
masih mengira bahwa saldonya sangat mencukupi untuk melakukan transfer karna
data yang diambil adalah data sebelum autodebet berlangsung. Jumlah saldo akhir
baru akan muncul ketika transaksi yang dilakukan si A berakhir, atau setelah
kartu atm dikeluarkan dari mesin atm dan dimasukkan kembali untuk pengecekan
ulang saldo. Penyelesaian dalam kasus ini adalah, seharusnya bank menggunakan
metode exclusive lock ketika transaksi autodebet
berlangsung sehingga ketika waktu autodebet dimulai, semua transaksi yang
memakai / membaca data dari bank harus dihentikan sampai proses autodebet
commit.
Dalam kasus ini, ketika ada nasabah yang sedang melakukan transaksi
ketika transaksi autodebet berlangsung, maka seharusnya otomatis akan muncul
pesan error di mesin atm yang menandakan sedang berlangsung transaksi di bank,
sehingga untuk sementara data tidak dapat dibaca sampai proses transaksi
selesai (commit). Dengan begitu, maka si A yang tadi akan melakukan transfer
akan seketika sadar bahwa saat itu sedang berlangsung proses autodebet dan dia
tidak bisa melakukan transaksi dulu sebelum transaksi di bank berakhir, atau A
harus menghentikan dulu transaksi yang dilakukan sampai transaksi di bank
selesai dan si A dapat mengetahui saldo akhir tidak mencukupi untuk melakukan
transfer.