0

いくつかのcrud操作を実行するためのAPIを提供しています。これは、既存の内部実装を使用します。さらに実装したのは、アプリケーションレベルのロックがこれらの操作を実行するのを確実に待機/再試行するロックメカニズムです。再試行すると、エラー テキストとともにカスタム例外がスローされます。コードレビュー中に、この待機を行うべきではなく、代わりに api のユーザーがこれを処理する必要があると言われました。

このロック待機を実装から削除する必要がありますか?

        lockManager = new LockManager();
        aquiredLock = lockManager.aquireLock();
        final int numberOfRetries = 3;
        final int sleepTime = 1000;
        int retryAttempt = 0;
        while (!aquiredLock.isLockAquired() && retryAttempt < numberOfRetries) {
            retryAttempt++;
            try {
                Thread.sleep(sleepTime);
            } catch (InterruptedException e) {
                throw new CannotAcquireLockException(e.getMessage(), e);
            }
            aquiredLock = lockManager.aquireLock();
        }

よろしく、ゴーサム

4

2 に答える 2

3

このようなことは一概に決められません。コード レビュー担当者は、おそらく問題のドメインについてよく知っているので、彼らのアドバイスは十分に正当化されるでしょう。

一般的な観点から、あなたが示している種類のコードは、それを行うためのデフォルト/明白な方法ではなく、このアプローチが実際に必要であることが状況から明らかな場合にのみ呼び出されるとしか言えません。

于 2012-08-30T11:56:15.913 に答える
1

提供するAPIに応じて、あなたの選択です。私にとっては、この代替手段があります

  • メソッドにロック待機メカニズムを残します。利点: このロックの問題を気にする必要がないため、ユーザーにとっては簡単です。欠点: API ユーザーはタイムアウトや再試行を行うことができません。

  • ロックを取得しようとしただけで、取得できなかった場合はスローします。利点: ユーザーは再試行/タイムアウト戦略を自分で決定できます。

どちらの場合も、API で選択を文書化する必要があります。レビュー プロセスで重要なことは、この選択が API の他の部分 (同じロックに関する他のメソッド) と一致しているかどうか、およびこのロックが本当に必要かどうかがわかることです。

補足: このアプリケーション (データベース エンジン) では、ロックを取得/解放する API を提供し、API 呼び出しでロックが実際に保持されていることをテストします。

于 2012-08-30T12:00:04.847 に答える