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]
