Sebenarnya solusinya agak sedikit kurang bagus sih untuk mengatasi masalah poison message di MDB ini, tapi bagaimana lagi….. Poison message itu sebenarnya message yang diterima oleh MDB dari JMS sedemikian rupa sehingga waktu diolah di MDB-nya membuat error di bisnis logic. Sehingga exception dilempar dan diketahui oleh container EJB, kemudian melakukan proses rollback transaction. Rollback transaction akan diikuti proses redelivery message oleh JMS ke recipent, dalam hal ini MDB itu sendiri. Jika itu berlanjut, maka otomatis proses akan berulang-ulang tanpa henti. Ini bisa menghabiskan load di server.

Nah, berhubung penulis masih belajar , maka salah satu solusinya (sesuai dengan yang dibuku sih) adalah dengan memberi penanda khusus untuk tiap message ID. Jadi jika proses sudah berulang kali dilakukan dengan message ID yang sama, maka jika sudah melebihi batas redelivery message count-nya, message akan di discard dan tidak masuk dalam bisnis logic. Dengan begitu MDB akan berjalan aman, gak akan terjadi pengulangan proses dengan message ID yang sama.

Tapi sebenarnya yang mengganjal itu adalah proses catch exception yang dikeluarkan oleh JDBC (pake JPA). Karena memang tidak tertangkap baik di sisi MDB-nya. Jadinya akal-akalan dengan melihat contoh kasus di forum, yang menggunakan entity manager untuk menyimpan ke DB; dengan cara setelah memanggil command persist, harus diikuti oleh command flush. Dengan begitu exception yang dikeluarkan di bisnis logic (khususnya di JPA-nya) dapat di catch. Meskipun penulis pikir yang ke catch itu EJBException-nya, soalnya sebelumnya dilihat di log, proses berulang-ulang itu akan throw 2 exception, satu adalah toplink JDBCnya dan EJBException sendiri (ini kayaknya bagian containernya).

Saat ini udah kehandle pake cara tadi itu, cuman ya itu tadi; belum ketemu untuk nge-catch Database Exceptionnya…. yah … sambil jalan aja lah…..

admin General