Why do we use transaction Control statements?

We use transaction control statements — Database.setSavepoint() and Database.rollback() — to gain fine-grained control over what gets undone when something fails in a multi-step transaction. By default, Apex transactions are all-or-nothing: an uncaught exception rolls back everything since the transaction began. Sometimes that’s too coarse.

The use case

Imagine a single trigger that does three things:

1. Inserts an Order header.
2. Inserts ten line items.
3. Calls a downstream class to update inventory.

If inventory update fails, you have a choice:

• Default behaviour: any uncaught exception rolls back all three steps — order, line items, and inventory write. The transaction never happened.
• With savepoints: you can roll back only the inventory step and commit the order + line items, perhaps marking the order as “Pending Inventory” for a retry.

Savepoints give you the middle ground.

The two statements

// 1) Mark a point in the transaction
Savepoint sp = Database.setSavepoint();

// 2) Roll back to that point — undoes every DML done after the savepoint
Database.rollback(sp);

Everything between setSavepoint() and rollback(sp) is undone — inserts, updates, deletes. State before the savepoint stays committed (within the same transaction; commits to the DB still happen at the transaction end).

A worked example

public class OrderService {
    public void placeOrder(Order__c header, List<Line_Item__c> items) {
        Savepoint sp = Database.setSavepoint();
        try {
            insert header;
            for (Line_Item__c li : items) li.Order__c = header.Id;
            insert items;

            InventoryService.reserve(items); // may throw
        } catch (Exception e) {
            Database.rollback(sp);  // undo header + items, leave caller's prior work intact
            header.Status__c = 'Inventory Failed';
            insert header;          // commit a placeholder record
        }
    }
}

Without the savepoint, the Order__c insert in the catch block would be wasted — the runtime would roll back the whole transaction when placeOrder returned with an unhandled exception anyway.

Why this matters: governor-limit caveats

Rolling back a savepoint does not free the SOQL/DML/CPU you’ve already used. Limits accumulate across the whole transaction regardless of rollbacks. If you’ve consumed 99 SOQL queries before the rollback, you still only have 1 left after.

What rollback does release:

• Record locks — taken during DML, released by the rollback.
• Database state changes — inserts/updates/deletes are reverted.
• Id values assigned during the rolled-back inserts — they’re discarded, so don’t reuse them after rollback.

When you don’t need savepoints

• No fallback action — if a failure means “fail the whole transaction,” the default uncaught-exception behaviour is fine.
• Read-only logic — SOQL doesn’t take locks the way DML does.
• Async jobs — each execute() call in Batch Apex is its own transaction; failures are scoped already.

When you do

• Partial-success orchestration — the order example.
• External callout retry — if the callout fails, roll back local writes that were predicated on it.
• Multi-step ETL — apply step 1, save, try step 2; if step 2 fails, leave step 1 intact (sometimes via savepoint, sometimes via stage flags).
• Bulk uploads — process records in groups; if one group fails, save the rest, log the failures.

The alternative: Database.insert(list, false)

For most “I want successful records saved and failed ones reported” cases, the simpler tool is partial-success DML:

Database.SaveResult[] results = Database.insert(records, false);

This avoids savepoints entirely. Reach for setSavepoint/rollback when the unit of failure is multiple DMLs that must succeed or fail together, not individual records.

What interviewers are really looking for

The basic answer is “to undo work after an error.” The senior answer adds: (1) default Apex transactions are all-or-nothing, so savepoints are only worth it when you want finer-grained rollback, (2) rolling back doesn’t restore governor budget (SOQL/DML/CPU counters keep going), (3) Database.insert(list, false) is the simpler tool for partial-success per record, (4) savepoints are most valuable for multi-step operations that must roll back atomically — order + line items + inventory.

Verified against: Apex Developer Guide — Transaction Control. Last reviewed 2026-05-17.