Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.This theme is Bloggerized by Lasantha Bandara - Premiumbloggertemplates.com.
Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.This theme is Bloggerized by Lasantha Bandara - Premiumbloggertemplates.com.
Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.This theme is Bloggerized by Lasantha Bandara - Premiumbloggertemplates.com.
Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.This theme is Bloggerized by Lasantha Bandara - Premiumbloggertemplates.com.
Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.This theme is Bloggerized by Lasantha Bandara - Premiumbloggertemplates.com.
Masing-masing memiliki kelebihan dan kekurangan masing-masing yang tidak akan kita bahas di artikel ini. Kali ini kita hanya akan membahas metode Spring JDBC dan perbandingannya dengan JDBC murni.
Artikel ini merupakan bagian pertama dari rangkaian artikel Spring JDBC, yaitu
Menggunakan JDBC polos tanpa library memang mudah, karena tidak perlu pusing mempelajari library lain. Tapi ada beberapa keterbatasan dan kesulitan, diantaranya:
semua method throws Exception, sehingga kode program kita menjadi kotor dengan try-catch
tidak ada manajemen koneksi database, kita harus buka-tutup sendiri
tidak ada declarative transaction, kita harus secara manual melakukan begin-commit/rollback
Dengan berbagai keterbatasan tersebut, ada baiknya kita menggunakan bantuan Spring Framework, yaitu modul spring-jdbc untuk memudahkan berbagai kegiatan di atas. Tentunya masih banyak hal yang harus kita lakukan sendiri, tidak seperti penggunaan library Object Relational Mapping (ORM) seperti Hibernate atau JPA, di antaranya:
mapping dari result set menjadi Java object
mapping dari Java object menjadi isi parameter PreparedStatement
cache
cascading operation
generate primary key secara otomatis
dsb
Ada beberapa tahapan dalam menggunakan Spring JDBC, yaitu :
Konfigurasi Koneksi Database
Membuat class Data Access Object (DAO)
Membuat class implementasi business process/service
Membuat test otomatis menggunakan JUnit
Studi Kasus
Agar lebih konkrit, kita akan menggunakan skema database yang umum digunakan di aplikasi bisnis, yaitu memiliki tabel :
Master Data / Referensi
Header Transaksi
Detail Transaksi
Berikut adalah skema database yang akan kita gunakan:
Selanjutnya, kita membuat konfigurasi database untuk Spring. Kita beri nama saja file konfigurasinya spring-jdbc-ctx.xml dan kita letakkan di folder src/main/resources. File ini berisi :
konfigurasi data source untuk koneksi ke database. Kita menggunakan pustaka commons-dbcp untuk menangani connection pooling ke database.
transaction manager. Ini dibutuhkan supaya kita tidak perlu lagi membuat coding untuk rangkaian begin-commit/rollback.
component scan. Ini dibutuhkan agar object DAO dan Service kita otomatis dideteksi dan diinisialisasi oleh Spring
Koneksi ke database sebetulnya merupakan operasi yang mahal. Kenapa mahal? Karena setiap kali kita membuat koneksi, ada serangkaian kegiatan yang harus dilakukan oleh database server seperti:
memeriksa username dan password
memeriksa apakah komputer kita (dilihat dari alamat IP atau nama host) diijinkan untuk masuk
memeriksa apakah database, tabel, dan tindakan yang kita lakukan memiliki ijin akses yang mencukupi
Oleh karena itu, idealnya koneksi database dibuat sekali saja dan digunakan terus sepanjang aplikasi berjalan. Tentunya kalau koneksi database hanya satu, setiap request dari user akan mengantri. Untuk itu kita buat banyak koneksi sekaligus yang nantinya akan dipinjamkanpada request yang membutuhkan. Teknik ini disebut dengan istilah database connection pooling.
Library yang kita gunakan untuk itu adalah Apache Commons DBCP, yang ditandai dengan penggunaan class org.apache.commons.dbcp.BasicDataSource di atas.
Ada banyak hal yang bisa disetting, tapi kita akan fokus ke beberapa saja yaitu:
driverClassName : nama class untuk koneksi ke database. Ini harus sesuai dengan merek dan versi database yang digunakan
url : informasi koneksi database. Biasanya berisi alamat server (IP atau Hostname) dan nama database
username : username untuk connect ke database
password : passwordnya user tersebut
Keempat informasi di atas adalah informasi umum yang kita butuhkan apapun metode koneksi database yang kita gunakan, tidak terkait dengan penggunaan Apache Commons DBCP. Konfigurasi berikut barulah berkaitan dengan Apache Commons DBCP:
maxActive : jumlah koneksi yang boleh aktif secara berbarengan. Ini harus disetting dibawah angka yang kita ijinkan di database server. Misalnya di MySQL kita ijinkan 100 koneksi berbarengan, maka angkanya harus dibawah 100. Jangan juga dihabiskan 100, untuk berjaga-jaga siapa tahu kita butuh koneksi langsung ke MySQL tanpa lewat aplikasi (misalnya untuk keperluan debug). Pertimbangkan juga apabila ada aplikasi lain yang menggunakan database yang sama.
maxIdle : ada kalanya aplikasi kita sedang sepi dari request user sehingga banyak koneksi database yang menganggur (idle). Angka maxIdle ini menentukan berapa koneksi yang akan tetap dipegang walaupun idle. Bila ada 20 koneksi idle, padahal maxIdle berisi 15, maka 5 koneksi akan ditutup. Ini merupakan trade-off. Bila terlalu banyak idle, maka memori database server akan terpakai untuk koneksi yang standby ini. Tapi bila terlalu sedikit, pada waktu aplikasi mendadak diserbu user, akan butuh waktu lama untuk dia membuatkan lagi koneksi baru.
maxWait : bila semua koneksi sebanyak maxActive sedang terpakai semua, request berikutnya akan menunggu salah satu selesai menggunakan koneksi. Nilai maxWaitmenentukan berapa milidetik request tersebut menunggu. Bila lebih dari maxWait dan belum juga kebagian koneksi, maka request tersebut akan mendapatkan Exception. Konfigurasi ini perlu diperhatikan karena nilai defaultnya adalah indefinitely yaitu menunggu selamanya.
Saya pernah mendapatkan masalah karena setting default ini. Aplikasi bengong seolah hang. Dicek ke log file tidak ada error. Ternyata masalahnya ada query yang kurang optimal sehingga memakan waktu lama. Pada saat banyak request yang menjalankan query tersebut, request lain menunggu lama tanpa ada pemberitahuan, sehingga terkesan hang. Setelah nilaimaxWait saya ganti menjadi 30 detik, mulai banyak error message bermunculan dari request yang menunggu > 30 detik. Dengan adanya error message, query bermasalah tersebut menjadi terlihat sehingga bisa diperbaiki.
Pesan moral pertama : pesan error itu penting untuk mengetahui sumber masalah. Dalam bugfixing, yang paling penting adalah menemukan masalah. Kalau masalah sudah ditemukan, siapa saja bisa memperbaiki. Jadi kalau aplikasi kita bermasalah, prioritas pertama kita adalah membuat dia mengeluarkan pesan error yang jelas.
Baca artikel ini untuk mengetahui apa yang dimaksud dengan pesan error yang jelas.
Pesan moral kedua : Dalam bugfixing, sering kali kita tidak langsung mendapatkan masalah utama. Pada kasus di atas, pertama kali saya menemukan bahwa perilaku defaultnya Commons DBCP adalah menunggu koneksi dengan sabar sampai selamanya. Setelah ini diubah, barulah saya menemukan masalah utama, yaitu ada query yang tidak optimal.
Transaction Manager
Setelah terhubung ke database, selanjutnya kita akan mengkonfigurasi transaction manager. Ini adalah fitur dari Spring Framework yang membebaskan kita dari coding manual untuk urusan transaction. Bila tidak menggunakan ini, maka kode program kita akan tampak seperti ini:
123456789101112131415161718
publicvoidsimpan(Produkp){Connectionconn;// inisialisasi koneksi di sinitry{conn.setAutocommit(false);Stringsql="insert into m_produk ... ";conn.createStatement().executeUpdate(sql);conn.commit();}catch(Exceptionerr){conn.rollback();}finally{conn.setAutocommit(true);conn.close();}}
Untuk dua baris perintah seperti di atas, kita harus menambahkan 8 baris hanya untuk mengurus transaction pada setiap method. Bayangkan kalau aplikasi kita punya 100 method, maka kode program untuk mengelola transaksi saja sudah 800 baris. Dengan fitur transaction manager, maka method di atas bisa ditulis ulang seperti ini:
12345
@Transactionalpublicvoidsimpan(Produkp){Stringsql="insert into m_produk ... ";conn.createStatement().executeUpdate(sql);}
Jauh lebih bersih dan rapi. Kode program jadi mudah dibaca dan akibatnya tentu memudahkan kita pada waktu bugfix, perubahan, ataupun penambahan fitur.
Class transaction manager yang digunakan berbeda tergantung metode akses database yang digunakan dan juga bagaimana cara kita mendeploy aplikasi. Beberapa pilihan transaction manager yang lain antara lain:
DataSourceTransactionManager : digunakan untuk koneksi database menggunakan javax.sql.DataSource. Ini artinya koneksi langsung dari aplikasi ke database server.
JtaTransactionManager : digunakan bila aplikasi kita dideploy di application server yang memiliki transaction manager sendiri (seperti Glassfish, JBoss, Websphere, Weblogic, dsb) dan menggunakan transaction manager yang disediakan tersebut. Bila kita deploy di Tomcat, hampir pasti kita tidak menggunakan JTA. Bila kita deploy ke Glassfish dan menggunakan konfigurasi dataSource Apache Commons DBCP, berarti kita juga tidak menggunakan JTA.
HibernateTransactionManager : seperti ditunjukkan oleh namanya, gunakan ini bila kita menggunakan Hibernate
JpaTransactionManager : ini juga sudah jelas dari namanya. Bila kita pakai JPA, gunakan transaction manager ini.