2009-09-07 9 views
5

私はいくつかの管理画面を持つWebアプリケーションを作成しています。ユーザーはレコードの編集に行くことができます(たとえば、ユーザーの連絡先の詳細を変更するなど)。これらの管理画面へのアクセスはロールによって制御され、複数のユーザーがアクセスできる可能性があります。 2人のユーザーが同時に同じレコードを編集しようとすると、何がすべきかという問題が発生します。並行変更のためのWebフロントエンド設計

私の問題はフロントエンドで、バックエンドではありません。ユーザーフレンドリーで同時修正を防ぐためにページを設計するために使用できるパターンは何ですか?私が考えることができる唯一の2つのオプションは、次のとおりです。

  • ペシミスティックロック:セッションがタイムアウトするのを待つ必要があるWeb環境では、ほとんどの場合ロックを解除できません。
  • オプティミスティック・ロッキング:最後に「保存できません」というメッセージで挨拶されるように大きなフォームを記入する可能性があるため、使い勝手の面ではそれほど優れていません。

+0

オプティミスティックロックは、ユーザーフレンドリーまたはそれ以外とは関係ありません。それは実装に至りました。大きな問題は、同じレコードの同時編集の予想頻度はどれくらいですか?低い場合、単純な楽観的なロックが勝ちます。 – SteveD

答えて

2

タイムリーな予約はどうですか?これは、多くのオンライン予約システムで使用されるモデルです。

単純な単一テーブルの場合の例(もっと多くのテーブルに拡張することが望ましい)RESERVATION_TIMEという名前のテーブルに列を追加します。すべてのレコードには、最初に「何年も前の」予約時間が設定されています。

オプティミスティック・ロックと組み合わせて使用​​します。編集モードに入る時点で

  • は、あなたがより30分前に今どこKEY = idとRESERVATION_TIMEへ

    UPDATEのRESERVATION_TIME

するレコードの予約を行いますこれは誰も最近更新を設定していない場合にのみ有効です。他のユーザーがすでに作業している場合、編集画面にデータが表示されないようにすることも考えられます。しかし、私たちはその予約を30分後に期限切れにして、何も "永久に"ロックされないようにしました。しかし、我々は悲観的なロックを保持しているわけではないことに注意してください。

  • は今すぐ(予約を取ったとして、多分旅館同じTRAN)ライトバックに

  • データを取得楽観的述語をチェックして、昔に戻って予約をクリアします。

ここでは、予約システムを尊重するすべてのアプリケーションの2人のユーザーを仲介します。オプティミスティック・ロックは、システムのすべての楽観的なユーザーの間を仲介します。したがって、ユーザーが苛立つ可能性はありますが、帯域外の更新はまれであると仮定すると、許容可能なユーザビリティを得るはずです。

いくつかの他のアイデア:

  1. 最終勝利を救う - いくつかのデータのロックにはポイントがありません。あなたは、ユーザーのBillにアリスの仕事を変更させ、その逆も許可するようにしていたので、勝つこともできます。
  2. 競合を検出し、マージします。 CVSソース管理システムと同様。オプティミスティックスキームを使用し、競合が発生した場合は、介在するアップデートと提案されたアップデートを提示し、競合を解決するようにユーザーに依頼します。
  3. 私たちは似たような状況(またはオプティミスティック・ロック)の最初の書き込み - 勝利のメカニズムを実装
+0

提案していただきありがとうございますが、ご予約のご提案を詳しくお聞かせください。私はまったくフォローしていません - あなたは予約のような悲観的なロックを使うべきですか、排他的なロックを持っていなければ楽観的なロックを許していますか? – Zecrates

+0

回答が少し更新されました – djna

1

BACKEND:

(これは自動的にMSSQL上で更新されたデータベースにタイムスタンプフィールドを作成します。

タイムスタンププロパティを含むオブジェクトを編集用に読み込むと、タイムスタンプが同じ場合にのみストアドプロシージャに保存することができます。それ以外の場合はエラーをスローし、アプリケーションでこれを処理しますレコードが変更されたことを示し、ページを再読み込みする機会を与えます。これはウェブ/切断された環境でうまくいきます。

FRONT END

ページには、変化を検出するために(AJAXを使用して)データベースをポーリングする必要があります。変更のプロンプトが表示された場合、レコードを示すユーザーが変更され、再読み込み/マージのオプションが変更されました。ページポストバックでは、コピーできる右側に新しい入力値(readonly)を表示するラベルまたはセカンダリフォームフィールド(読み取り専用)。たとえば、矢印ボタンを左に向けて値を元のフォームフィールドにコピーします。

+0

これは楽観的なロックですね。質問者が問題を抱えているのは、ユーザーがUIに多くの詳細情報を入力して10分を費やしてしまった場合には、とても親切なことです。 "あまりにも遅れています!もう一度タイプしてください。" – djna

+0

"楽観的なロック"と良い点:-)ありがとう。回答が更新されました。 –

0

私はオプティミスティックロックは使いやすいものではないことに同意します。

  • はより頻繁にロックを解除するには、データベースに、ロックをdelaiを使用することができます。悲観的ロックするための

    は、私はあなたが問題を乗り越えることができると思います。その後、Delaiの有効期限が切れ、別のユーザーがロックを解除する可能性があります。最初のユーザーに通知されます。それは最初から明確にする必要があります。

  • また、ロックページで自動リフレッシュを繰り返すこともできます。それぞれの(ajax)リクエストで、あなたは時間を覚えています。したがって、サーバー上のロックがリフレッシュレートよりも古い場合は、ユーザーがこのページにもう存在しないことを意味します。セッションが期限切れになっていなくても、ロックをクリーンにすることができます。

0

あなたは、変更されたレコードを取得し、それらが提出されたデータとの比較を示すことにより、オプティミスティック・ロックのユーザーフレンドリーにすることができます。

これをさらに進めて、競合を編集するためのTortoiseSVNのようなインターフェイスを実装できます(ある場合)。

これには少しのUIが必要になることがありますが、同時に編集することができます。

nice diff interfaceの作成方法の例として、Rietveldで使用されているHTML/JS/CSSコードを確認してください。

関連する問題