Httpロック解除を待つときのステータスコードが長くかかるのはなぜですか？

Question

ロックメカニズムを使用して、2つの並列呼び出しが同じ行を更新して予期しない動作を引き起こしていないことを確認しています。だから私のコードは次のようなものです：（実際の例はありません）

public class UserController { 
    public ActionResult AddReputation(int id, int repAmount) { 
    int lockWait=0; 
    bool alreadyLocked=true; 
    while (alreadyLocked) { 
     alreadyLocked=GetLockForUser(id); 
     Thread.Wait(1000); 
     lockWait++; 
     if (lockWait>10) { 
      return new HttpStatus(xxx); 
     } 
    } 
    SetlockForUser(id); 
    AddUserRep(id,repAmount); 
    return new Content("Well Done"); 
    } 
    } 

So. 10秒後にもロックが残っている場合は、「後でもう一度試してください。他の誰かがそのユーザーのデータを保存しています」という発呼者に伝えたいと思います。

そのためのREST-APIで最高のHTTPコードは何でしょうか？ 409 Conflict？または423 Locked？

注：これはSQL-DBではありません。私は実際の取引はありません。だから自分のロック機構を実装する必要があります。

Answer 1

クライアントはこの状況で何をしたいですか？

あなたの説明から、クライアントの唯一の選択肢は、待機して後で再試行するように聞こえます。だから、503 (Service Unavailable)はぴったりのように思える：

は、サーバーが現在による可能性が高い。また、いくつかの遅延

後に軽減される一時的な過負荷や定期保守にリクエストを処理できないことを示していますジェネリック500 (Internal Server Error)はいつもあなたのサービスのもとにあります。

423（ロックされている）が適切かもしれません。 WebDAV’s locking mechanismsの一部として設計されています。クライアントは、リソースを明示的にロックおよびロック解除します。一般に、クライアントは423エラー（WebDAV外では珍しい）よりも503エラー（一般的には非常に一般的）を理解する可能性が高くなります。423は一般的なclient errorとして扱われる可能性があります。つまり、the definition of 423 itselfでは、WebDAVのロックを必要としません。この状況をサーバーのダウンタイム（503という結果になる）と区別したい場合は、423が機能します。

409 (Conflict)はないを行いぴったりのように見える：

このコードは、ユーザーが競合を解決し、要求を再送信することができるかもしれない状況で使用されています。