Serializability Tujuan dari concurrency control adalah melakukan penjadwalan transaksi untuk menghindari terjadinya interferensi antartransaksi dan masalah yang ditimbulkan. Salah satu solusinya dengan mengizinkan hanya satu transaksi yang dieksekusi dalam selang waktu tertentu. Namun, tujuan dari multi-user DBMS juga memaksimalkan level concurrency atau parallelism dalam sistem sehingga beberapa transaksi dapat dieksekusi secara paralel tanpa menginterferensi satu sama lain. Oleh karena itu, untuk mengidentifikasi transaksi-transaksi yang dapat dieksekusi secara paralel dan tetap dapat menjaga konsistensi pada sistem perlu dilakukan pemeriksaan serializability. Schedulesebuah urutan operasi dari serangkaian transaksi yang sedang berlangsung bersamaan dengan menjaga urutan operasi pada setiap transaksi.

Serial schedulesebuah penjadwalan (schedule) yang mengeksekusi operasi dari setiap transaksi secara berturut-turut tanpa disela oleh operasi dari transaksi lain.

Nonserial schedulesebuah penjadwalan (schedule) yang mengeksekusi operasi dari transaksi-transaksi yang sedang berlangsung bersamaan secara bergantian.

Gambar Equivalent schedules : (a) nonserial schedule S1; (b) nonserial schedule S2 ekuivalen dengan S1; (c) serial schedule S3, ekuivalen dengan S1 dan S2Setiap pengeksekusian serial (serial execution) tidak akan membuat database dalam keadaan yang tidak konsisten, tetapi dapat menghasilkan keadaan akhir yang berbeda dengan serial execution lain. Tujuan dari serializability adalah mencari nonserial schedule yang mengizinkan transaksi dieksekusi bersamaan tanpa menginterferensi satu sama lain dan menghasilkan database state yang dapat dihasilkan oleh suatu serial execution. Jika nonserial schedule yang dijalankan menghasilkan keadaan akhir yang sama denga beberapa serial execution, maka schedule tersebut disebut serializable. Conflict SerializabilityDalam serializability, pengurutan untuk operasi read dan write penting untuk diperhatikan. Batasannya sebagai berikut : Jika ada dua transaksi read untuk sebuah data item, kedua transaksi tersebut tidak akan menyebabkan konflik sehingga pengurutan transaksinya bebas. Jika ada dua transaksi baik read ataupun write untuk data item yang berbeda, kedua transaksi tersebut tidak akan menyebabkan konflik sehingga pengurutan transaksinya bebas. Jika ada satu transaksi write untuk suatu data item dan satu transaksi lainnya yang read atau write pada data item yang sama, pengurutan transaksinya perlu diperhatikan karena dapat menyebabkan konflik . Schedule S3 pada gambar merupakan serial schedule dan karena S1 dan S2 ekuivalen dengan S3, maka S1 dan S2 merupakan serializable schedules. Tipe serializability ini dinamakan conflict serializability. Conflict serializable schedule mengurutkan operasi-operasi yang konflik menjadi sama seperti serial execution. Precedence/serialization graph dapat digunakan untuk menguji conflict serializability. Precedence graph adalah sebuah grafik berarah G= (N,E) yang terdiri dari serangkaian node N dan serangkaian garis berarah E yang dibuat dengan prosedur berikut ini : Membuat node untuk setiap transaksi. Membuat garis berarah Ti Tj, jika Tj membaca nilai dari item yang ditulis oleh Ti. Membuat garis berarah Ti Tj, jika Tj menulis nilai untuk item yang baru dibaca oleh Ti. Membuat garis berarah Ti Tj, jika Tj menulis nilai untuk item yang baru ditulis oleh Ti.Jika terdapat Ti Tj pada grafik schedule S, maka Ti harus muncul sebelum Tj pada serial schedule S yang ekuivalen dengan S. Jika pada precendence graph terdapat siklus (cycle) schedule, maka schedule tersebut bukan merupakan conflict serializable. Gambar Precedence graph untuk transaksi T9 dan T10 menunjukkan sebuah siklus maka kedua transaksi tersebut bukan merupakan conflict serializable. View SerializabilityDua schedule S1 dan S2 yang terdiri atas operasi-operasi yang sama dari n transaksi T1,T2, . . ., Tn dapat disebut sebagai view equivalent jika memenuhi tiga kondisi berikut ini : Untuk setiap data item x, jika transaksi Ti read nilai awal dari x pada schedule S1, maka transaksi Ti juga harus read nilai awal dari x pada schedule S2. Untuk setiap operasi read data item x oleh transaksi Ti pada schedule S1, jika nilai x yang akan dibaca telah ditulis oleh transaksi Tj, maka transaksi Ti juga harus read nilai x yang dihasilkan oleh transaksi Tj pada schedule S2. Untuk setiap data item x, jika operasi write terakhir untuk x dilakukan oleh transaksi Ti pada schedule S1, maka transaksi yang sama juga harus melakukan write terakhir untuk data item x pada schedule S2.Sebuah schedule merupakan view serializable jika schedule tersebut merupakan view equivalent dengan sebuah serial schedule. Setiap conflict serializable schedule merupakan view serializable, namun tidak sebaliknya. Schedule pada gambar merupakan view serializable, tetapi bukan merupakan conflict serializable. Transaksi T12 dan T13 tidak sesuai dengan batasan pada aturan write, keduanya melakukan blind write. Seperti yang terlihat pada gambar, view serializable schedule yang bukan merupakan conflict serializable mempunyai satu atau lebih blind writer. Gambar View serializable schedule yang bukan merupakan conflict serializable.Pendekatan untuk pengecekan view serializability suatu schedule adalah dengan membuat labeled precedence graph untuk schedule tersebut sebagai berikut:(1) Membuat node untuk setiap transaksi.(2) Membuat sebuah node berlabel Tbw. Tbw merupakan transaksi dummy yang dimasukkan pada awal schedule yang mengandung operasi write untuk setiap data item yang diakses pada schedule.(3) Membuat sebuah node berlabel Tfr. Tfr merupakan transaksi dummy yang ditambahkan pada kahir schedule yang mengandung operasi read untuk setiap data item yang diakses pada schedule.(4) Membuat garis berarah Ti Tj, jika Tj membaca nilai dari sebuah item yang ditulis oleh Ti.(5) Menghilangkan semua garis berarah pada Ti jika tidak ada jalur (path) dari Ti ke Tfr.(6) Untuk setiap data item yang ditulis oleh Ti kemudian dibaca oleh Tj dan juga ada Tk yang menulis data item tersebut (Tk Tbw), maka:(a) Jika Ti = Tbw dan Tj Tfr, maka membuat garis berarah Tj Tk.(b) Jika Ti Tbw dan Tj = Tfr, maka membuat garis berarah Tk Ti.(c) Jika Ti Tbw dan Tj Tfr, maka membuat sepasang garis berarah Tk Ti dan Tj Tk, x adalah positif integer yang unik dan belum digunakan sebelumnya untuk melabeli garis berarah. Berdasarkan aturan ini, jika transaksi Ti menulis suatu item yang kemudian Tj membacanya, maka transaksi Tk yang menulis item yang sama harus dilakukan sebelum Ti atau sesudah Tj.

Gambar Labeled precedence graph untuk view serializable schedule pada gambar Berdasarkan labeled precedence graph, tes untuk view serializability adalah sebagai berikut:(1) Jika pada grafik tidak terdapat siklus (cycle),maka schedule merupakan view serializable.(2) Keberadaan siklus belum cukup untuk menyimpulkan bahwa schedule bukan merupakan view serializable. Tes yang sebenarnya didasarkan pada pengamatan terhadap aturan 6(c) yang menghasilkan m pasangan garis berarah sehingga terdapat 2m grafik yang berbeda-beda dan memuat hanya satu garis dari setiap pasang. Jika salah satu grafik asiklik, maka schedule tersebut merupakan view serializable dan urutan serializability-nya ditentukan oleh pengurutan topologi grafik dengan menghilangkan Tbw dan Tfr dari transaksi dummy.

Gambar Modifikasi dari schedule pada gambar dengan menambahkan operasi read.

Gambar Labeled precedence graph untuk schedule pada gambar memiliki 1 pasang garis berarah (b) sehingga terdapat 21 grafik berbeda yaitu (c) dan (d). Schedule ini merupakan view serializable karena ada salah satu grafik yang asiklik.RecoverabilitySerializability mengidentifikasi schedule yang memelihara konsistensi database dengan asumsi tidak ada transaksi dalam schedule yang gagal. Jika suatu transaksi gagal, atomicity property mengharuskan kita untuk membatalkan efek dari transaksi tersebut. Selain itu, berdasarkan durability property, jika suatu transaksi commit, maka perubahan yang terjadi tidak dapat dibatakan (tanpa menjalankan transaksi atau kompensasi lain). Contoh kasus, diasumsikan transaksi T9 pada gambar tidak commit melainkan memutuskan untuk roll back efek dari transaksi, sedangkan T10 tetap membaca nilai balx yang dihasilkan oleh T9 lalu melalukan update balx dan commit perubahan tersebut. Untuk kasus tersebut, T10 seharusnya dibatalkan karena T10 menggunakan nilai balx yang dibatalkan, akan tetapi durability property tidak mengizinkannya. Oleh karena itu, schedule tersebut disebut nonrecoverable schedule.Recoverable scheduleuntuk setiap pasangan transaksi Ti dan Tj pada sebuah schedule, jika Tj membaca suatu data item yang sebelumnya telah ditulis oleh Ti, maka operasi dari Ti commit sebelum operasi dari Tj commit.

Teknik Concurrency ControlAda dua teknik utama concurrency control yang memungkinkan transaksi diekseskusi secara paralel dengan aman dan memenuhi batasan tertentu, yaitu metode locking dan timestamp. Namun, locking dan timestamping merupkan pendekatan yang konservatif/pesimistik yang menyebabkan transaksi ditunda jika bertentangan dengan transaksi lain. Metode optimistik didasarkan pada premis bahwa konflik jarang terjadi sehingga memungkinkan transaksi diproses secara tidak sinkron dan konflik hanya diperiksa saat transaksi commit.Metode LockingLocking

Prosedur yang digunakan untuk mengontrol akses terhadap suatu data yang terjadi bersamaan. Jika satu transaksi sedang mengakses database, sebuah lock akan menolak akses dari transaksi lainnya untuk mencegah hasil akhir yang tidak benar.

Ada beberapa variasi metode locking, tetapi semua memiliki karakteristik yang sama, yaitu suatu transaksi harus mengklaim shared (read) atau exclusive (write) lock pada data item sebelum database membaca atau menulis operasi. Exclusive lock akan mencegah transaksi lain membaca atau memodifikasi data item tersebut. Data item dengan berbagai ukuran, mulai dari seluruh database sampai field dapat dikunci. Ukuran item ini menentukan lock granularity.Shared lockJika suatu transaksi memiliki shared lock pada suatu data item, transaksi tersebut dapat membacanya (read) tetapi tidak dapat mengubahnya (update).

Exclusive lockJika suatu transaksi memiliki exclusive lock pada suatu data item, transaksi tersebut dapat membaca dan mengubahnya.

Lock digunakan dengan cara berikut: Transaksi yang ingin mengakses sebuah data item harus mengunci item terlebih dahulu, mengajukan shared lock hanya untuk akses membaca atau exclusive lock untuk akses membaca dan menulis. Jika item belum dikunci oleh transaksi lain, maka penguncian akan diberikan. Jika item sedang dikunci, DBMS akan menentukan permintaan mana yang sesuai dengan kunci yang ada. Jika shared lock diajukan pada item yang telah memiliki shared lock, maka permintaan akan dipenuhi, jika tidak, transaksi harus menunggu sampai kunci yang ada dilepas. Transaksi akan terus mempertahankan kunci (lock) sampai dilepas baik selama eksekusi atau saat eksekusi selesai (abort atau commit). Efek dari operasi write yang dibuat pada item dengan exlusive lock akan ditampilkan kepada transaksi lain hanya pada saat kunci dilepas.Beberapa sistem mengizinkan transaksi untuk memberikan shared lock pada suatu item dan kemudian meningkatkannya (upgrade) menjadi exclusive lock. Selain itu, beberapa sistem juga mengizinkan transaksi untuk memberikan exclusive lock dan kemudian menurunkannya (downgrade) menjadi shared lock. Penggunaan lock dalam transaksi tidak menjamin serializability dari schedule. Contoh kasus, aturan locking untuk schedule pada gambar adalah sebagai berikut:S = {write_lock(T9, balx), read(T9, balx), write(T9, balx), unlock(T9, balx), write_lock(T10, balx), read(T10, balx), write(T10, balx), unlock(T10, balx), write_lock(T10, baly), read(T10, baly), write(T10, baly), unlock(T10, baly),commit(T10), write_lock(T9, baly), read(T9, baly), write(T9, baly), unlock(T9, baly), commit(T9)}

Jika sebelum eksekusi , balx = 100 dan baly = 400, maka hasil akhirnya adalah balx = 220 dan baly = 330, jika T9 dieksekusi sebelum T10, atau balx = 210 dan baly = 340, jika T10 dieksekusi sebelum T9. Sementara itu, hasil akhir dari eksekusi schedule S adalah balx = 220 dan baly = 340. Oleh karena itu, S bukan merupakan serializable schedule.

Permasalahan pada contoh kasus di atas adalah pelepasan kunci suatu transaksi dilakukan segera setelah operasi read dan write dieksekusi dan item yang dikunci (balx) tidak diakses lagi oleh transaksi tersebut. Namun, transaksi itu mengunci item lainnya (baly) setelah melepaskan kunci pada balx. Meskipun ini lebih memungkinkan concurrency yang mengizinkan transaksi untuk mengganggu transaksi lainnya, tetapi ini dapat menghilangkan isolasi total dan atomicity. Untuk menjamin serializability, kita harus mengikuti protokol tambahan mengenai penentuan posisi operasi lock dan unlock pada setiap transaksi. Protokol yang paling terkenal adalah two-phase locking (2PL).Two-phase Locking (2PL)2PL

Suatu transaksi mengikuti protokol two-phase locking jika semua operasi penguncian dilakukan sebelum operasi pelepasan kunci (unlock) pertama pada transaksi tersebut.

Berdasarkan aturan pada protocol ini, setiap transaksi dapat dibagi menjadi dua fase, yaitu growing phase dan shrinking phase. Pada growing phase, transaksi memperoleh semua kunci yang dibutuhkan, tetapi tidak dapat melepaskan kunci. Sementara itu, pada shrinking phase, transaksi melepaskan kunci-kuncinya tetapi tidak dapat memperoleh kunci baru. Aturan-aturan pada protocol ini adalah sebagai berikut: Transaksi harus memperoleh kunci pada suatu item sebelum melakukan operasi pada item tersebut. Kunci yang didapat bisa read atau write, tergantung tipe akses yang dibutuhkan. Setelah transaksi melepaskan kunci, transaksi tersebut tidak akan dapat lagi memperoleh kunci baru.Peningkatan (upgrading) kunci hanya dizinkan selama growing phase dan transaksi perlu menunggu sampai transaksi lain melepaskan shared lock pada item tersebut. Sementara itu, penurunan (downgrading) kunci hanya diizinkan selama shrinking phase.Pencegahan kehilangan pembaruan (lost update) dengan 2PL

Gambar Masalah kehilangan pembaruan (lost update)Solusi untuk permasalahan kehilangan pembaruan (gambar) ditunjukkan pada gambar. Untuk mencegah terjadinya kehilangan pembaruan, T2 meminta exclusive lock pada balx terlebih dahulu sehingga dapat melakukan proses read nilai balx dari database, menambahkannya dengan 100, dan menulis nilai yang baru ke database. Ketika T1 mulai, transaksi ini juga meminta exclusive lock pada balx. Karena data item balx sedang dikunci secara eksklusif oleh T2, permintaan dari T1 tidak segera dipenuhi dan T1 harus menunggu sampai T2 melepaskan kuncinya. Pelepasan kunci oleh T2 terjadi pada saat commit T2 selesai.

Gambar Pencegahan masalah kehilangan pembaruanPencegahan masalah dependensi yang tidak commit (dirty read) dengan 2PL

Gambar Masalah dependensi yang tidak commitSolusi untuk masalah dependensi yang tidak commit (gambar) ditunjukkan pada gambar. Untuk mencegah masalah ini terjadi, T4 meminta exclusive lock pada balx terlebih dahulu sehingga dapat melakukan proses read nilai balx dari database, menambahkannya dengan 100, dan menulis nilai yang baru ke database. Saat rollback dieksekusi, pembaruan dari transaksi T4 akan dibatalkan dan nilai balx di database dikembalikan ke aslinya. Saat T3 mulai, transaksi ini juga meminta exclusive lock pada balx. Karena data item balx sedang dikunci secara eksklusif oleh T4, permintaan dari T3 tidak segera dipenuhi dan T3 harus menunggu sampai T4 melepaskan kuncinya. Pelepasan kunci oleh T4 terjadi pada saat rollback T4 selesai.

Gambar Pencegahan masalah dependensi yang tidak commitPencegahan masalah analisis yang tidak konsisten dengan 2PL

Gambar Masalah analisis yang tidak konsistenSolusi untuk masalah analisis yang tidak konsisten (gambar) ditunjukkan pada gambar. Untuk mencegah masalah ini terjadi, T3 harus mendahului proses read dengan exclusive lock, dan T6 harus mendahului proses read dengan shared lock. Oleh karena itu, saat T5 mulai, transaksi ini meminta dan mendapatkan exclusive lock pada balx. Lalu, ketika T6 mencoba untuk meminta shared lock, permintaan ini tidak segera dipenuhi dan T6 sampai pelepasan kunci saat T5 commit..

Gambar Pencegahan masalah analisis yang tidak konsistenJika setiap transaksi dalam suatu schedule mengikuti protokol two-phase locking, maka dijamin schedule tersebut menjadi conflict serializable. Namun, walaupun protokol two-phase locking menjamin serializability, bisa saja terjadi masalah yang berkaitan dengan pelepasan kunci seperti contoh berikut ini:Pada gambar, transaksi T14 memperoleh exclusive lock pada balx kemudian memperbaruinya menggunakan baly yang diperoleh dengan shared lock, dan menuliskan kembali nilai balx ke database sebelum melepaskan kunci pada balx. Lalu, transaksi T15 memperoleh exclusive lock pada balx, kemudian membaca nilai balx dari database, memperbaruinya, dan menulis kembali nilai yang baru ke database sebelum melepaskan kunci. Setelah itu, T16 baru bisa shared lock pada balx dan membacanya dari database. Akan tetapi, T14 gagal dan harus roll back sehingga menyebabkan T15 yang bergantung padanya juga harus roll back. Oleh karena itu, T16 yang bergantung pada T15 juga harus roll back. Situasi ini dinamakan cascading rollback.

Gambar Cascading rollbackCascading roll back dapat dihindari dengan menerapkan salah satu variasi two-phase locking berikut: rigorous 2PL dan strict 2PL. Rigorous 2PL mengharuskan semua kunci untuk dipegang sampai transaksi commit. Sementara itu, strict 2PL mengharuskan semua kunci mode eksklusif untuk dipegang sampai transaksi commit. Kebanyakan sistem database mengimplementasikan salah satu dari variasi 2PL tersebut. Permasalahan lain yang bisa terjadi dengan two-phase locking adalah deadlock. Jika dua transaksi masing-masing menunggu kunci yang dipegang oleh transaksi lainnya, maka kan terjadi deadlock. Namun, bisa juga terjadi livelock pada transaksi, yaitu transaksi yang terus dalam keadaan menunggu untuk jangka waktu yang tidak terbatas. Hal ini disebabkan algoritma antrian untuk transaksi yang tidak adil dan tidak memperhitungkan lamanya transaksi menunggu. Untuk menghindari lifelock, dapat digunakan sistem prioritas seperti antrian first-come-first-served untuk transaksi yang menunggu.DeadlockDeadlockKebuntuan yang terjadi saat dua (atau lebih) transaksi masing-masing menunggu pelepasan kunci yang dipegang oleh transaksi lainnya.

Contoh kasus deadlock dapat dilihat pada gambar. Pada waktu t6, transaksi T17 meminta exclusive lock pada baly, tetapi karena T18 memegang kunci pada baly maka T17 harus menunggu. Sementara itu, pada waktu t7, T18 meminta kunci pada balx yang sedang dikunci oleh T17. Oleh karena itu, tidak ada transaksi yang dapat berjalan karena keduanya menunggu kunci yang tidak akan didapat sampai transaksi lainnya selesai. Satu-satunya cara untuk menghentikan deadlock adalah dengan membatalkan satu atau lebih transaksi.

Gambar Deadlock antara dua transaksiTiga teknik umum yang digunakan untuk penanganan deadlock adalah sebagai berikut: TimeoutsPendekatan sederhana untuk mencegah terjadi deadlock adalah dengan lock timeouts. Dengan pendekatan ini, transaksi yang meminta kunci hanya akan menunggu selama jangka waktu yang ditetapkan oleh sistem. Jika kunci tidak juga diberikan selama jangka waktu tersebut, maka permintaan kunci tersebut time out. Dalam hal ini, DBMS mengasumsikan transaksi mengalami deadlock, walaupun mungkin tidak, lalu DBMS akan menggagalkan dan menjalankan kembali transaksi tersebut secara otomatis.

Deadlock preventionPendekatan lain untuk mencegah deadlock adalah dengan mengurutkan transaksi menggunakan transaction timestamps. Ada dua algoritma yang diusulkan oleh Rosenkrantz, yaitu:1. Wait-Die, algoritma ini hanya mengizinkan transaksi lama menunggu transaksi baru, jika tidak transaksi dibatalkan (dies) dan dijalankan kembali dengan timestamp yang sama, sehingga pada akhirnya transaksi tersebut menjadi transaksi aktif yang paling lama dan tidak akan die.2. Wound-Wait, algoritma ini menggunakan pendekatan simetrikal: hanya transaksi baru yang dapat menunggu transaksi lama. Jika transaksi lama meminta kunci yang dipegang oleh transaksi baru, maka transaksi baru akan dibatalkan (wounded).Variasi 2PL yaitu conservative 2PL juga dapat digunakan untuk mencegah terjadinya deadlock. Dengan menggunakan conservative 2PL, sebuah transaksi mendapatkan semua kuncinya saat transaksi mulai atau menunggu sampai semua kunci tersedia. Protokol ini memiliki keuntungan jika permintaan kunci pada item banyak maka waktu pemegangan kunci dikurangi karena transaksi tidak pernah diblokir sehingga transaksi tidak pernah menunggu untuk mendapatkan kunci. Kemudian, pada protokol ini kunci harus diperoleh dan dilepaskan semua dalam satu waktu sehingga jika transaksi gagal memperoleh satu kunci maka transaksi tersebut harus melepaskan semua kunci yang sudah didapatkan dan memulai proses penguncian lagi. Deadlock detection and recovery Pendeteksian deadlock biasanya menggunakan wait-for-graph (WFG) yang menunjukkan ketergantungan transaksi. WFG adalah grafik berarah G = (N,E) yang terdiri dari serangkaian node N dan garis berarah E yang dibangun dengan ketentuan berikut ini: Membuat node untuk setiap transaksi Membuat garis berarah Ti Tj, jika transaksi Ti sedang menunggu untuk mengunci suatu item yang sedang dikunci oleh TjDeadlock terjadi jika terdapat siklus pada WFG, seperti pada gambar.

Gambar WFG dengan cycle Frekuensi pendeteksian deadlockKarena siklus pada WFG menunjukkan adanya deadlock, maka algoritma pendeteksian deadlock membangun WFG pada setiap interval waktu dan memeriksa adanya siklus. Pemilihan interval waktu sangat penting. Jika interval terlalu pendek, pendeteksian deadlock akan menambah overhead. Jika interval terlalu panjang , deadlock mungkin tidak dapat terdeteksi untuk jangka waktu yang panjang. Oleh karena itu,diperlukan pendeteksian deadlock secara dinamis yang dimulai dengan nilai awal interval.

Pemulihan dari pendeteksian deadlockKetika deadlock dideteksi, maka DBMS perlu untuk membatalkan satu atau lebih transaksi dengan mempertimbangkan beberapa persoalan berikut:1. Pemilihan korban deadlockUntuk menentukan mana transaksi yang akan dibatalkan, dapat dipertimbangkan beberapa hal berikut ini:a) Berapa lama transaksi sudah berjalan (lebih baik membatalkan transaksi yang baru dimulai saja)b) Berapa banyak data item yang telah diperbarui oleh suatu transaksi (lebih baik membatalkan transaksi yang hanya membuat perubahan kecil pada database)c) Berapa banyak data item yang masih sedang diperbarui oleh suatu transaksi (lebih baik membatalkan transaksi yang sudah melakukan banyak perubahan pada database2. Sejauh mana suatu transaksi di-rollbackSaat memutuskan untuk membatalkan suatu transaksi, harus diputuskan juga sejauh mana transaksi di-rollback. Membatalkan semua perubahan yang telah dibuat oleh suatau transaksi adalah solusi sederhananya. Rolling back hanya sebagian dari transaksi kemungkinan juga dapat menanganani deadlock. 3. Menghindari starvation.Starvation terjadi saat transaksi yang sama selalu terpilih sebagai korban (victim) sehingga transaksi tersebut tidak pernah bisa complete. Starvation mirip dengan livelock . DBMS dapat menghindari starvation dengan cara menyimpan jumlah berapa kali masing-masing transaksi dipilih menjadi victim dan menggunakan kriteria seleksi yang berbeda saat jumlahnya mencapai upper limit.