エンティティのロック
ALM Octaneの楽観的ロックを使用して、APIリクエストが相互に干渉しないようにし、データの損失を防ぎます。
概要
ALM Octaneは、optimistic lockingを使用して、同じエンティティに同時に変更を加えたときのデータ損失を防ぎます。ALM Octane REST APIを使用する場合は、これと同じ戦略を実装することをお勧めします。
client_lock_stampフィールドを使用して、REST APIを使用した楽観的ロックを容易にします。このフィールドは、データの損失と競合を防ぐためにエンティティをロックする必要がある変更のみを追跡します。これらの変更が発生すると、client_lock_stampがインクリメントされます。client_lock_stampは、エンティティのロックを必要としない変更が行われた場合はインクリメントされません。
注: エンティティの内部サーバー側の変更やサーバー側でのビジネスルールの実行の結果である変更など、すべての変更にロックが必要なわけではありません。
ロックを必要としない変更の例は次のとおりです。位置属性 (グリッド内のインデックス) の変更、および階層関係など、エンティティの [詳細] ペインで読み取り専用であるエンティティ間のいくつかの関係。
version_stampフィールドは、ロックスタンプの増分を必要としない変更を含む、エンティティのすべての変更に対して増分されます。version_stampフィールドとclient_lock_stampフィールドの両方があると、ALM Octaneはデータを不必要にロックすることなく更新を実行できます。
クライアントデータの正確性を検証し、偶発的なオーバーライドを回避するには、すべての更新 (PUT) リクエストでclient_lock_stampフィールドを送信します。
次に、サーバーはバージョンを検証し、不一致がある場合は500、Internal Server Errorを返します。
更新要求の一部としてclient_lock_stampを送信しない場合、サーバーは検証しません。
例
エンティティの更新中にエンティティをロックする例を次に示します。
どちらの例でも、client_lock_stampがリクエストの一部として送信されます。
client_lock_stampがエンティティのスタンプと一致しません。Error 500, Internal Server Error,が返されます。
*** Request ***
PUT .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/defects/4444
{ "description": "This is my updated description", "client_lock_stamp": 3 }
*** Response ***
{ "error_code": "platform.version_conflict", "correlation_id": "loj0p1ol3q3ksggogmomx2wr7", "description": "Other users have updated this entity. Refresh the entity to get these updates and re-apply your changes.", "description_translated": "Other users have updated this entity. Refresh the entity to get these updates and re-apply your changes.", "properties": { "entity_type": "defect", "entity_id": "4444" }, "stack_trace": ... ... ... ... "business_error": true }
*** Request ***
PUT .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/defects/4444
{ "description": "This is my updated description", "client_lock_stamp": 4 }
*** Response ***
{ "type": "defect", "id": "4444" }
参照情報: