シナリオ： ユーザーは、/ DBは時々悪いcomm.linkでモバイルデバイスを使用して自分のWebアプリケーションにデータを書き込んでいる（GPRS）GWT-RPCタイムアウトの期限が切れ
私は重複したデータが欲しいドントとして、タイムアウトが中にありません彼らの書き込み要求が、これは時々彼らがアシストコールバックが到着するのを待っていることを意味します。
RpcRequestBuilderを通じて、RPC要求にタイムアウトを追加できますが、期限が切れた場合は、データが保存されているかどうかを知る方法があります。サーバ？
これを達成するために私が見る唯一の方法でないなら、私のデータベースのユニークな制約があります。リクエストがタイムアウトして失敗した場合は、事前
で
Tyが、それはペイロードデータを保存することができましたかどうかを知るための唯一の100％の方法は、別の要求を送信し、データが正しく保存されたかどうかを確認することです。
この状態は、UNKNOWN状態と呼ばれる必要があります。タイムアウトだけでなく、サーバー側でのエラー処理の悪さなど、クライアント/サーバーおよびマルチティアアプリケーションの開発時には常にこの問題に直面します。あなたはサーバーへのコールを分類する必要があります。私はこれを好きです、トランザクション、お問い合わせ、そして重要です。これらのタイプの通話にこのようなタイプの障害が発生した場合、お客様のケースで何が起こっているのか（サーバーで何かが変更または更新される）私は彼/彼女のリクエストを処理中に接続が切断されたことをユーザーに通知し、また、再実行を試みる前にトランザクションを再度チェックする必要があることを知らせます（主キーまたは参照がある場合は、ユーザーの動作を確認することができます）。お問い合わせの場合は、無視してもう一度お電話ください。最後のタイプの場合、通常はお問い合わせですが、アプリケーションが機能するためには重要ですので、別の方法で処理します。
これは、コールを分類するという概念を持つことが重要な理由です。
Alaa
非常に低いタイムアウト値（LANでは5ms）を設定して独自のテストを行いました。その結果、実際にはサーバーにデータが格納されることがありますが、応答がクライアントに到着する前にタイムアウトになります。 – jpp1jpp1