Why does Database class not provide commit method so that we can commit explicitly as well while in a transaction as we can do a rollback.

1 Answer 1


We can't control commits, because there's too much system logic that depends on us not being able to commit directly to the database. For example, if we performed a commit and the transaction later failed, we would have committed data we can't roll back, but the remaining data hasn't been finalized, so we are left with a database in a possibly corrupt state; we then have to explicitly undo whatever we did up to the commit point.

Also, things like sending emails also commit records to the database. If we committed an email that contained some data, then the records themselves failed to save to the database, the email would be sent in error. There's simply too many complications with allowing users direct access to the database. This is why we have a database application layer exposed to us-- Salesforce abstracts the Oracle database away from us, so we can focus on business needs (CRM), rather than managing a database.

I could mention a ton of reasons why explicit commits would be a bad idea. It's hard enough to get commits "just right" when we're given our own databases (e.g. MySQL), without trying to predict how our commits might affect the underlying system logic. I do find myself wishing there was a way to side-commit records that should survive a failed transaction, but that's not a feature we have right now.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .