マルチスレッド・プログラミングの落とし穴、その２
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
InfoQ: JavaScriptへのマルチスレッド・プログラミングの導入
function backgroundLoad ( ids ) { for ( var i=0; i < ids.length; i++ ) { var a = getArticleWithCache(ids[i]); backgroundLoad(a.children); } } このbackgroundLoadはIDの配列を引数に取り、その各IDに対して上で定義したgetArticleWithCacheを呼び出します。これでIDに対応する記事のデータがキャッシュされます。そして読み込んだ記事の子記事のIDに対してbackgroundLoadを再帰的に呼び出すことで、ツリー全体をキャッシュすることができます。 ここまですべてうまくいっているように見えます。しかし、一度でもAjax開発を経験したことのある方ならば、これではうまくいかないということはすでにおわかりだと思います。これまでの例で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
