> Hehehehehe gw ga mau ngasih ikan, tapi kasih pancingan, coba renungkan > kenapa servlet itu pake pool,
SingleThreadModel deprecated bozz as of Servlet 2.4 http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/SingleThreadModel.html >> Kaknya ga juga, meskipun singleton kalo methodnya ga dibikin >> synchronized ya ga perlu ngantri. Bisa aja ada 2 thread yang >> mengeksekusi method tsb pada saat bersamaan. >> Iya yah..kenapa SLSB pake pool, kalo SFSB sih masuk akal. >> >> Apakah supaya developer ga perlu dipusingin soal issue thread-safe? sepertinya begitu bozz http://forum.springframework.org/archive/index.php/t-28881.html Gw rangkumin dikit : Alasan utama kenapa SLSB dibuat thread adalah karena EJB guaranteed kalau semua eksekusi dalam Session Bean itu thread safe, walaupun kita menyimpan variabel ataupun object yang nggak thread save. Kalau kita bisa menjamin bahwa Spring service singleton yang kita buat tidak mempunyai member variabel (variabel yang ada dalam class, bukan local variabel yang ada dalam method) dan tidak mempunyai member variabel dari class yang not-thread-safe maka singleton kita selamat, tanpa error. Berikut contoh2 kasus dan kodenya: Kasus pertama, full stateless object. Tidak ada member variabel sama sekali. Kasus ini kalau kita pake Spring service singleton selamat, SLSB juga selamat public class FooStatelessService { public int doIt(int i) { return i*i; } } Kasus kedua, Full statefull. Terlihat ada member variabel i yang hrus diinisialisasi terlebih dahulu sebelum method doIt() dilaksanakan. Kalau pake singleton bisa berabe, pake SLSB selamet. Pada waktu satu request menjalankan setI dilanjutkan doIt ada kemungkinan thread lain menjalankan setI dengan nilai berbeda, sehingga ketika request pertama menjalankan doIt akan menghasilkan kembalian yang tidak diharapkan. public class FooStatefulService { private int i; public void setI(int i) { this.i = i; } public int doIt() { return i*i; } } Jadi apakah hanya class yang tidak mempunyai member variabel sama sekali yang thread-safe? ternyata tidak begitu adanya, class thread-safe boleh mempunyai member variabel asalkan member variabel tersebut berasal dari class yang thread-safe pula Kasus ketiga, statefull tapi thread-safe, selamet pake singleton atau pake SLSB, karena class DataSource thread-safe public class FooThreadsafeService { private Datasource ds; public setDs(Datasource ds) { this.ds = ds; } public void doIt() { /* do some db magic here*/ } } Kasus keempat, statefull tapi not-thread-safe, nggak selamet pake singleton harus pake SLSB, karena class SimpleDateFormat not-thread-safe. public class FooNonThreadsafeService { private SimpleDateFormat sdf; public setSdf(SimpleDateFormat sdf) { this.sdf = sdf; } public void doIt() { /* do some date formatting here*/ } } Tapi apakah method class pada kasus keempat harus diimplementasikan pake SLSB? ternyata tidak harus, kita bisa membuat work aroundnya. Seperti terlihat dibawah ini, yang diletakkan sebagai member variabel adalah string, dan String adalah class thread-safe. Sehingga class di kasus keempat dapat diimplementasikan dengan singleton jika kita mengubahnya menjadi seperti kode di bawah ini. public class FooThreadsafeAgainService { private String sf; public setSf(String sf) { this.sf = sf; } public void doIt() { SimpleDateFormat sdf = new SimpleDateFormat(sf); /* do some date formatting here*/ } } Kesimpulanya adalah, kalau class kita benar-benar stateless atau fully thread-safe cukup gunakan singleton, SLSB tidak relevan. tetapi membuat class yang stateless/thread-safe punya tantangan tersendiri. SLSB menghindarkan programmer dari kewajiban memastikan bahwa class kita stateless dan thread-safe, karena setiap request akan diberi satu instance SLSB dari pool, jika ada request lain yang nyaris bersamaan akan diberi instance SLSB yang lain. Jadi EJB guarantee one instance SLSB per request. CMIIW -- Senior Engineer @ ArtiVisi Intermedia Java Training Center See our course @ artivisi.com http://ifnu.artivisi.com +62 856 9211 8687 regards
