B: Using partial DML statements (e.g.,Database.insert(list, false)) allows only valid records to be committed while identifying invalid ones, avoiding runtime errors. D: TheDatabase.Savepointmethod ensures transactional control by allowing rollback to a specific savepoint if an error occurs. Why not other options? A: The@ReadOnlyannotation is for read-only operations and would not allow DML operations. C: TheSystem.Limitclass helps monitor limits but does not directly control transaction behavior. Best Practices for Apex Transactions
最新のコメント (最新のコメントはトップにあります。)
正:C,D
正解は **C** と **D** です。
問題文にある「リソースを大量に消費する」「トランザクション制御を確実にする」「ガバナ制限の超過を回避する」という要件に対し、それぞれの選択肢がどのように機能するか解説します。
### 正解の解説
**C. System.Limits クラスを使用して、現在の CPU ガバナー制限の消費を監視します。**
* **理由:** 「リソースを大量に消費するアクション」を行っている場合、最も懸念されるのは **CPU時間制限 (Apex CPU time limit exceeded)** です。
* `System.Limits` クラス(例: `Limits.getCpuTime()` と `Limits.getLimitCpuTime()`)を使用することで、制限に達する前に処理を検知し、適切にループを中断したり、残りの処理をスキップしたりする「予防的なロジック」を実装できます。これがガバナ制限超過の回避に直結します。
**D. データベースの整合性を強化するには、Database.Savepoint メソッドを使用します。**
* **理由:** 「トランザクション制御を確実にする」ための機能です。
* ループ内でDMLを実行している途中でエラー(例外やガバナ制限など)が発生した場合、それまでに行った更新が中途半端に残ってしまう可能性があります。
* `Database.setSavepoint()` でセーブポイントを作成し、エラー時に `Database.rollback()` することで、**処理全体をなかったことにする(ロールバックする)** ことができ、データベースの整合性を保つことができます。
---
### 不正解の解説
**A. @ReadOnly アノテーションを使用して、SOQL によって返される行数をバイパスします。**
これは **不正解** です。
`@ReadOnly` アノテーションを使用すると、SOQLの取得行数制限は緩和されますが、そのトレードオフとして **DML操作(insert, updateなど)が一切禁止** されます。
問題文に「このメソッドは... DML ステートメントも実行します」とあるため、このアノテーションを使用するとエラーになります。
**B. 有効なデータのみがコミットされるように、部分的な DML ステートメントを使用します。**
これは **不正解** です。
「部分的なDML (`Database.insert(list, false)`)」は、エラーがあっても処理を続行する機能ですが、これは「トランザクション制御(一貫性の保証)」とは逆の動き(一部だけ成功させる)になります。また、これを使ったからといって CPU時間などのガバナ制限が回避できるわけでは...
正:C,D