Loading
Salesforce から送信されるメールは、承認済ドメインからのみとなります続きを読む

永続的オブジェクトでの楽観的ロックの仕組み

公開日: Aug 26, 2025
説明
チェックアウト時に注文を作成できなかったり、ジョブから注文をエクスポートできない問題に顧客が遭遇する場合があります。エラーログの例外の一部に次のメッセージが記載されています。 
com.demandware.beehive.orm.capi.common.ORMOptimisticLockingException: Optimistic locking failure. Object couldn't be updated.
解決策
スレッドが永続的オブジェクト (PO) を ORM から読み出すときに、楽観的制御の属性 (OCA) の値がスレッドに認識されます。スレッドが PO を更新または削除するときに、スレッドは PO の UUID と OCA を使用して PO を識別します。つまり内部的には、次の擬似 SQL では UPDATE/DELETE 操作の WHERE 句に UUID と OCA の両方のコラムが含まれます。 
UPDATE/DELETE ... WHERE UUID='foo' AND OCA=1
一般的に、楽観的ロックの失敗は 2 つのスレッドが同じ UUID と OCA をもつ PO を更新しようとしたときに発生します。スレッドの種類はどれでも構いません。

このような楽観的ロックの失敗の原因を説明するために、OrderPO を例にユースケースを示します。注文が行われると、次の表のようになります。UUID は foo、EXPORT_STATUS は NOTEXPORTED、OCA は 1 です。ここで重要なのは OCA の値です。これは楽観的ロックのアプローチで使用される値で、オブジェクトが更新されると 1 ずつ増分されます。
 
UUIDEXPORT_STATUSOCA
fooNOTEXPORTED1
        

2 つのスレッドがあるとします。スレッド A は Business Manager で注文を操作するマーチャントから生成されたもので、スレッド B は注文をエクスポートするジョブが生成したものです。両方のスレッドに ORM キャッシュの同じ OrderPO があります。マーチャントが注文の EXPORT_STATUS を READY に変更しました。スレッド A は上記の UUID が foo で OCA が 1 に等しい OrderPO を識別して、EXPORT_STATUS を更新します。同時に、OCA が 2 に増分されて、次の表のようになります。
 
UUIDEXPORT_STATUSOCA
fooREADY2
     

同じ OrderPO の属性を、スレッド B が更新しようとします。OCA の値がスレッド A によって更新されているため、この時点で ORMOptimisticLockingException がスローされます。UUID が foo で OCA が 1 に等しい Or-derPO はもう存在しないため、スレッド B によって発行された更新操作にはゼロ行が返されます。これが楽観的ロックの仕組みです。永続的オブジェクトは最初からロックされていませんが、更新されるとマークされます。このアプローチは、オブジェクトにアクセスしている間に何も変更されないことを前提としており、そのため楽観的と呼ばれます。オブジェクトに対するハードロックではありません。一方、悲観的ロックのアプローチは、オブジェクトの更新中に何かが変更される可能性があることを前提としているため、オブジェクトを最初からロックしています。このアプローチは在庫リストなどに使用されます。
 
ナレッジ記事番号

000393690

 
読み込み中
Salesforce Help | Article