kalo udah main proses data segitu gedenya, mesti berani bikin yang kompleks-kompleks dan berat-berat. tapi hasilnya jadi bagus. memang untuk masalah "bulk processing", sangat-sangatlah kompleks urusannya. gak bisa sembarangan pake cara ini dan itu. dan pastinya gak bisa lagi pake cara-cara tradisional dan konvensional.
2008/6/5 T Budi S <[EMAIL PROTECTED]>: > 2008/6/5 Adelwin Handoyo <[EMAIL PROTECTED]>: > >> >> Khan tadi katanya langkah berikutnya yaitu optimasi pembacaan dari >> database >> khan? >> Jadi bongkar JDBC dong? :p > > Maksudnya scr high level :D > >> Bayangan gue bikin nya gini... >> For each row { >> String param = rs.getString(1); >> New SubProcess(param); >> } >> Class SubProcess ini akan extends Thread atau implement Runnable... >> tergantung mana yang lebih baik sih... >> Jadi while si SubProcess ini baru launch... iteration udah restart lagi >> dari >> atas... >> Lebih cepet... >> Yang perlu di itung adalah SubProcess ini akan jalan berapa lama... >> Dan iteration nya sendiri akan seberapa cepet... >> We don't want too many SubProcess(s) running at the same time... maybe a >> few >> hundred shoud be good lah.. >> > > Apakah maksudnya ada semacam Process pooling gitu ? Jadi kompleks donk ... > Tapi kalo ga dibatasi takutnya OutOfMemory, krn iterasi minimal aja > udah 10 ribu. > Prosesnya sendiri relatif cepat. No need to worry lah ... > > Skr overhead justru ada di pembacaan databasenya. > > thanks anyway :) > T Budi S > -- syaiful.mukhlis gtalk:[EMAIL PROTECTED]