3.6.4 で解決済みの課題
Atlassian の Jira チームが Jira Service Desk 3.6.4 のリリースを発表できることを、光栄に思います。
Jira Service Desk 3.6 をお持ちではありませんか?
Jira Service Desk 3.6 リリース ノートで、新機能とその他のハイライトをご確認ください。
2017 年 8 月 22 日にリリース済み
プラグイン開発者向け PSA
Jira Service Desk 開発チームは昨今、AbstractSingleFieldType に影響を与える競合状態を発見しました (この問題は https://jira.atlassian.com/browse/JSDSERVER-5299 で確認できます)。スレッドが値を更新する必要がある場合は、新しい行を追加する前に既存の値をすべて取得して、最後に古い行を削除して新しい値のみを残します。追加と削除の間に別のスレッドが呼び出されると、スレッドは 2 行を取得します。しかし、AbstractSingleFieldType は 1 つの値しか処理できないため、行の 1 つが破棄されます。この問題は JSD Server 3.6.4 で解決済みです。要約すると次のとおりです。
- スレッドがカスタム フィールドの値を更新すると、既存の値をすべて取得して、新しい値を含む新しい行を追加してから、古い値を破棄する。
- 追加と削除の間に別のスレッドが呼び出されると、1 行ではなく 2 行取得されるが customFieldValuePersister は 1 つの値のみを処理する。
- これを解決するには、最初の値を選択して他のすべての値を削除する。これらの値は日付順で明示的に順序付けされないため、古い値を選択して新しい値を削除できる。
この問題がフィールド内の以前の値に基づいて計算される値に影響することと、毎回第一原則から計算される他の値はこの問題の影響を受けないことに注意してください。この問題に対処するために、JSD 開発チームは次の措置を講じました。
- 「更新した」null 可能な列を customfieldvalue テーブルに追加して、結果を常に順序付けできるようにした。これによって、上記の競合状態が発生した場合に保持する最新の値を選択できる。
- UPDATE のトランザクションを行う。これらのステートメントのトランザクションを行うことによって、完了するまでコミットされない。つまり、最初の段階で競合状態が発生する可能性は低くなる。
注意点
JIRA (jira.customfield.values.cache) には RequestCache があり、カスタム フィールドの最後に取得した問題の値が格納されます。そのフィールドのデータに依存してプラグイン内のデータベースから常に読み込んでいる場合は、そのエントリを JiraAuthenticationContextImpl.getRequestCache から削除して、実際にデータベースに毎回アクセスする必要があります。