On Dec 18, 2007 3:49 PM, Arif Rachim <[EMAIL PROTECTED]> wrote: > > > Beberapa orang, termasuk saya, memilih untuk menghindari medan tempur > > appserver clustering, dan memilih 'bertarung' di external cache > > (seperti memcached). > > > > IMO, pendekatan saya lebih sederhana, less magic, dan lebih mudah > > didebug kalau ada apa2. > > Pindah appserver, no problem, karena gak ada vendor-specific > > clustering config yang harus saya pusingkan. > > Mau dideploy di winstone/jetty farm, no problem. > > > > But then again, pilihan masing-masing. > > > > Pasti abis ini saya dibilang Old School sama Arif > > :D > > :P Engga old school lah,setiap teknologi pasti ada alsannya. > > IMO cache itu tidak dapat digantikan, untuk kasus diatas tidak ada > hubungannya. Saya mengerti maksud mas endy ... kita menitik beratkan > di cache maksudnya kalau di request kita hanya menyimpan id saja, maka > pada saat request tersebut diproses kita load object tersebut maka > cache akan mengurangi performance overhead koneksi ke database. >
Jelas-jelas cache ada hubungannya. Cache menjadi salah satu alternatif solusi selain HttpSession. Banyak library cache yang mendukung distributed cache jadi ini harus dipertimbangkan sebagai alternatif dari HttpSession replication dan EJB3 clustering. > Untuk contoh kasus kita diatas, contoh sederhana shopping cart itu > tidak ada hubungannya dengan cache. Maksudnya gini, andaikan kita > punya object cart yang berisi collection of items, maka saat si user > login kita ingin menyimpan cart nya di session. Nah pada saat kita > akan update cart tersebut pasti kita akan retrieve dari session, add > item, kemudian set lagi ke dalam session. > > Nah kasus diatas kalau kita menggunakan httpSession replication maka > semua node akan di replicate object dari cart keseluruhan, bukan cuma > itemnya saja :) saat kita mengeset cart tersebut kedalam session. > Dari tadi kan yang diceritakan kelemahan HttpSession replication. Gimana kalo sekarang lu ceritain kelebihan EJB3 replication / clustering in depth. Biar keliatan apakah sama busuknya ato ga. > Terus kenapa kita tidak simpan saja kedalam database, salah satu > alasannya karena menyimpan kedalam database akan overkill, shopping > cart lifecyclenya pendek, jadi tidak efisien juga kalau harus disimpan > kedalam database setiapkali user mengupdate shopping cart tsb :) > > > > Sampai saat ini pakai Spring+Hibernate, saya tidak pakai OSIVF. > > Lebih sipp menentukan data apa yang mau digunakan di UI layer, > > kemudian menyediakan semua yang dibutuhkan supaya gak Lazy Loading. > > IMO setiap teknologi pasti ada alasannya. Kenapa ada lazy loading > tetapi tidak dimanfaatkan ?? IMO lazy loading adalah salah satu fitur > yang sangat "melegakan" developer java. Saya berani menantang ... > bahwa developer yang memanfaatkan object graph ORM seperti hibernate > atau JPA pasti codenya jauh lebih pendek dari pada developer yang > tidak menggunakan lazy loading :) misalnya menyiapkan seluruh object > yang dibutuhkan dalam Map sebagai "Model" kemudian di forward ke > servlet atau jsp. > Yup jumlah code memang lebih pendek, tapi butuh effort lebih untuk make sure tidak terjadi LazyInitializationException. Lagipula object yang diberikan hibernate itu kebanyakan (kalau tidak bisa disebut semua) sudah dikotori oleh hibernate. Perlu bagi developer untuk aware terhadap "auto save dirty property" oleh entity yang di-manage hibernate. > Selama ini kita terpaku bahwa web app stateless ... mungkin saatnya > kita lihat kacamata baru yang namanya statefull webapp. Lazy loading, > annotation, contextual component .... new buzz yang sangat menarik :) > Stateless application masih menjanjikan karena lebih simple. Biasanya framework yang menjanjikan Statefull application, seperti yang mas Endy katakan, membuat terlalu banyak "magic" yang kemungkinan buggy-nya besar sekali dan tidak kelihatan pada saat kita buat aplikasi 'hello world'. > Welcome to 2008 :-)
