Iya, untung sdh ada anggota tim yg khusus menangani masalah ini.
Thanks utk semua tanggapannya, kalau sdh ada solusi utk masalah ini
akan saya share.
regards,
T Budi S
2008/6/6 sm96 <[EMAIL PROTECTED]>:
> 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]
>
