サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内
論理削除と一意性制約を両立させる方法・DB製品別 - Qiita
アプリケーション上でなにかエントリ（例えば記事だとかユーザだとか）を削除したとき、DB上の行は削除せず単に【削除済み】フラグを立てるだけという扱い方を 論理削除 と呼びます。 論理削除にはいろいろなメリットがあります。行削除のように関連する他テーブルへ削除が波及しないこと、エントリ復活ができること、障害時にデータ変更の経緯を追いやすくなることなどなど（デメリットもわんさかあるんですが、この記事の主旨からははずれるので別途お調べください）。 ところが論理削除の方針でDBを組んでいて困ったことはありませんか？ 「 メールアドレスは一意性(UNIQUE)制約をかけたいのに、それだと削除済みのユーザと同じメールアドレスが使えないことになる 」 論理削除と一意性制約、両立はできないのか？ できないと思っている方、多いと思います。実はちゃんとできます。DB製品によって実現方法がちょっと違ってくるだけで
ジェネリック型引数を実行時型情報に残す方法がある - Qiita
Javaのジェネリックは1.4以前のバイナリ仕様との互換のために、コンパイルの時点で型引数情報が消去され非ジェネリックプログラミングされたかのようなコードに変換されます。この変換を 型消去（イレイジャ） と呼びます。 型消去、通常のプログラミングにもたまに影響を与えます（例えば List.toArray() がなぜか引数として一見不要な E[] 型の配列オブジェクトを要求するなどします）が、何より影響を受けるのがリフレクションごりごりのフレームワークプログラミングやライブラリプログラミングにおいてです。型消去に伴って、実行時型情報からも型引数の部分が抜け落ちてしまいますから（そこだけは残しておいてくれれば良かったのに！）。 具体的にはどんなことになるかというと、たとえばみんな大好きEBean（うそ、僕が大好き）なら、エンティティクラスを指定して対応するDBテーブルからデータを取り出すのに
JavaでRDBデッドロック検出 - Qiita
http://cs.hatenablog.jp/entry/2013/07/09/234554 RDB操作でデッドロックは不可避です。ご確認ください。 DBでのデッドロックの発生は、直ちにシステムが停止することを意味しません。DBMSはデッドロック発生を検出してトランザクションを失敗させる機能を持っているからです。 アプリケーションの開発者がすべきことはただ一点、 デッドロック検出時のリトライ です。更新処理だけじゃないです。参照処理でも忘れちゃいけません。約束です。 Javaの場合デッドロック発生はコード的にどう検知すればいいかというと、SQLExceptionが内部にSQLSTATEというRDB共通のエラー番号を持っているのでこれで判別可能となっています。 SQLSTATEの一覧は日立さんのこのまとめが役に立ちます。拝承。 http://www.hitachi.co.jp/Prod/c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
