12

私は、チケット作業システムに似た Web アプリケーションを使用しています。一部のユーザーは、新しい問題を入力します。他のワーカーは、問題を選択して解決します。すべてのデータは、MS SQL サーバー 2005 で維持されます。

問題の解決に取り組んでいるユーザーは、未解決の問題を表示できるページに移動します。最大 20 人が同時にこのページを見ることができるため、私が対処しなければならなかった潜在的な問題の 1 つは、ページが読み込まれた直後に他の誰かが選択した問題を誰かが選択した場合にどうなるかということでした。

これに対処するために、私は2つのことをしました。まず、選択する課題を表示するグリッドビューは、AJAX タイマーを使用して 1 秒ごとに更新します。問題が選択されると、最大で 1 秒後に消えます。この秒以内にいずれかを選択すると、別の選択を求めるメッセージが表示されます。

問題は、これの AJAX 部分があまりにも多くの更新を送信しており (これは私が想定していることです)、ページとデータベースのパフォーマンスに影響を与えていることです。さらに、更新は毎秒実行されません。ストアド プロシージャをトリガーする作業を行う場合、タイマーが信頼できないことがわかりました。

もっと良い方法があるはずですが、見つけられないようです。このような状況の経験がある人はいますか、または複数のユーザーが同じレコードを選択して維持しないようにするための提案はありますか? メッセージだけでアプリケーションを使用するのがイライラするので、AJAX部分を完全に無効にしたくありません。

ありがとう、

4

6 に答える 6

4

データベースの行にロック タイムスタンプ フィールドを配置します。有効期限の timsetamp が特定の時間より古い場合に true または false を返すストアド プロシージャを記述します。Web アプリでセッションを設定して、同じ時間、1 分から 2 分で期限切れになるようにします。ユーザーが行を選択すると、ユーザーが行を変更できるようにするかどうかをアプリが判断するのに役立つストアド プロシージャが呼び出されます。

それが理にかなっていることを願っています....

于 2008-10-27T02:50:33.477 に答える
3

2つのことが問題の軽減に役立ちます。

まず、ajaxの更新時間枠に関係なく、ケースが取得されたという選択後の通知が必要です。毎秒チェックしても、2人が同じ時間に同じケースをクリックできないわけではありません。このような場合、選択時に有効に見えたとしても、選択が無効であることをユーザーの1人に通知する必要があります。この通知は複雑である必要はありません。明るく役立つトーンを維持することで、失望した場合でもユーザーの認識を向上させることができます。そして、そのレコードをすでに選択したユーザーを特定すると、ユーザーが将来調整するのに役立つだけでなく、プログラムからジューシーなケースを蛇行したユーザーに注意をそらすことができます。（確かに、経営陣は好きかもしれませんケースをより早く選択するようにユーザーを動機付けるため、ユーザーに時折衝突を与える）

次に、ケースの表示方法を少し調整することで、選択の衝突を減らすことができます。表示順序にランダムな要素を追加したり、表示されている他のすべてのケースを除外したりすると、ユーザーはさまざまなケースを自然に選択できます。人間のパターン認識とタスクの選択は実際にはランダムではないため、プレゼンテーションの小さな変更は、選択動作の大きな変更と同じになる可能性があります。衝突の可能性が減少すると、衝突通知がまれになります（したがって、ユーザーのイライラが少なくなります）。これは、ユーザーを分類に分けて、有用なケースの順序付け/フィルタリングを決定するのに役立つ場合は、さらに優れています。

さて、時間の経過とともに役立つ3番目のことは、衝突が発生したときのログを保持するかどうかです（誰が関与したか、選択のタイミングなど、衝突に関する有用なメタデータを使用します）。確かな衝突データで武装して、何が機能し、何が機能しないかを見つけることができます。時間の経過とともに、アプリケーションを実際のユースケースに合わせて磨き、潜在的な問題を早期に特定することができます。問題が存在することに気付く前に、問題を把握している（そして問題を解決するための計画を説明できる）ことほど、ユーザーを安心させるものはありません。

これらの緩和パターンを使用すると、ユーザーエクスペリエンスに影響を与えることなく、ajaxクエリの時間枠を安全に短縮できることがわかるでしょう。また、便利なロギングを使用すると、行った調整が実際に機能している（または機能していない）ことが保証されます。これは、知っておくとさらに便利です。

于 2010-09-23T15:21:03.907 に答える
3

ユーザーがチケット（行）を開くと、そのチケットをそのユーザーに割り当て、そのレコードに値を設定します。たとえば、FKをその特定のユーザーに設定します。したがって、他の誰かがそのチケット（行）を開こうとした場合は、すでに他の誰かに割り当てられていることを彼らに知らせます。

于 2008-10-27T12:22:51.400 に答える
2

更新間隔を長くしてみましたか。30秒に1回で十分だと思います。40 リクエスト/分は、1200/分よりもはるかに少ない負荷です。ユーザーは違いに気付かないかもしれません。

もしそうなら、ユーザーが項目を選択する直前にリストを手動で更新できるように、ページに更新ボタンを提供して、ユーザーが選択した場合に迷惑なメッセージを回避することはどうですか.

于 2008-10-27T02:42:45.487 に答える
2

可能であれば、すべての未解決の問題から選択できるようにするのではなく、作業キューから次の未解決の問題を取得するようにシステムを制限します。

それが不可能な場合は、問題の選択時に、それがまだ利用可能かどうかを確認できると思います. 利用できない場合は、ユーザーがクリックした後に非表示にします。このようにして、データの絶え間ないポーリングとは対照的に、実際に何かをクリックしたときにのみリクエストします。

于 2008-10-27T02:44:06.797 に答える
1

特に、あなたがすでにチケットに進行中/維持中のフラグを立てており、アイテムのタイムスタンプ/バージョンを持っていると述べた後、私は問題を確認できませんでした.

以下で十分ではありませんか？

  1. ユーザーがチケットを参照すると、利用可能なチケットのリストが表示されます。つまり、進行中のデータベースにあるものは除外されます。ユーザーに進行中のチケットも表示したい場合は、チケットのステータスで明確に示し、チケットを取るオプションを無効にします。
  2. ユーザーは、チケットを開くことによって明示的または暗黙的に進行中としてチケットにフラグを立てます (ユーザー エクスペリエンス/ユーザーへの提示方法によって異なります)。
  3. ユーザーがチケットを別のステータス（完了、無効、フィードバック待ちなど）に明示的に移動します。

アイテムが 1 で取得されるときに、タイムスタンプ/バージョンを含めます。2 つが発生した場合は、楽観的同時実行アプローチを使用して、2 人が同時にテイクのチケットを更新しようとした場合に、最初の 1 つだけが成功するようにします。

何が起こるかというと、2 人目の update ... where ... timestamp = @timestamp は更新するレコードを見つけられず、チケットが既に取得されたことを報告します。

必要に応じて、上記の上に構築して、チケットが取得されたときに UI を更新できます。これは、x 時間後にチケットの現在のページを完全に更新する (おそらくユーザーに警告/プロンプトを表示する) か、ajax で表示されているチケットのページで変更されたチケットのリストを取得することによって行うことができます。この変更はユーザーにとって便利なだけであるため、以前の手順がまだ残っています。

于 2010-09-24T15:13:16.850 に答える