Webアプリケーションの構造は3層です。（プレゼンテーション層、ビジネス層、DB層）
すべてのビジネスロジックはビジネス層にあります。
プレゼンテーション層はビジネス層にCRUDを要求し、結果を取得してユーザーの要求を処理します。
ちなみに、プレゼンテーション層で読み取りタイムアウトを設定しました。（3秒）
この場合、ビジネスレイヤーからの結果が遅いと、ユーザーにエラーメッセージが表示され、CRUD処理が正しく終了します。したがって、ユーザーはアクションを再試行します。その結果、データが複製されます。
この問題を解決する方法は？読み取りタイムアウトを増やすだけですか？
3 に答える
0
ロールバックを実装し、タイムアウトに達した場合はそれを実行します。タイムアウトの前に終了した場合は、データベーストランザクションをコミットします。タイムアウトを増やしても何も解決されません。
于 2012-09-12T01:09:07.637 に答える
0
最善のオプションは、クライアントに要求のackを受信させてから、（後で）完了または失敗の確認を受け取ることです。これは、連絡が途絶えることや仕事が非常に遅いことを除いて、典型的なシナリオをカバーしています。
タイムアウトを増やすことは賢明です。3秒のタイムアウトは、最も深刻な作業には実用的ではありません（サーバーが一時的にビジーであるか、ネットワーク遅延がある場合はどうなりますか？）。
于 2012-09-12T03:18:51.740 に答える
0
ビジネス層で長時間実行されるトランザクションの場合、プレゼンテーション層にCOMETのようなメカニズムを実装する必要があります。
- ユーザーがトランザクションを送信すると、ビジネスレイヤーがすぐに戻ります
- トランザクションはビジネスレイヤーのバックグラウンドで実行されます
- プレゼンテーション層は定期的にビジネス層をポーリングして、トランザクションの状態を確認します
残念ながら、このメカニズムでは通常、プレゼンテーション層とビジネス層の両方でいくつかの重要な実装変更が必要です。クライアント側では、javascriptフレームワークがこれらの種類の機能をすぐに提供します。サーバー側では、サーブレット3.0にある非同期サーブレットが役立つ場合があります。
読み取りタイムアウトを増やすだけでも簡単ですが、ほとんどの場合、これから抜け出すことはできません。クライアントの要求がプロキシ/ファイアウォールなどを通過する場合、後者はプレゼンテーション層よりも先にタイムアウトして接続を閉じる可能性があります。
于 2012-09-12T05:08:47.957 に答える