Methods and systems for providing fault recovery to side effects occurring during data processing

• US 8,548,952 B2
• Filed: 03/08/2012
• Issued: 10/01/2013
• Est. Priority Date: 10/04/2006
• Status: Active Grant

• Current Assignee: Salesforce.com, Inc.
• Original Assignee: Salesforce.com, Inc.
• Inventors: Weissman, Craig, Tamm, Steven, Fell, Simon, Wong, Simon, Fisher, Steve
• Primary Examiner(s): Lee, Wilson
• Assistant Examiner(s): Le, Jessica N
• Application Number:
  US13/415,403
• Publication Number:
  US 20120166871A1
• Time in Patent Office: 572 Days
• Field of Search: 707/610, 707/661, 707/674
• US Class Current: 707/661
• CPC Class Codes: G06F 11/1474 in transactions G06F16/20 takes precedence

Abstract

Embodiments may recover from faults by forming a new set of rows by removing rows associated with faulting save operations and repeating the saving and forming operations using the new set of rows until a set of rows that can be saved from the known start state without fault is determined. When the subset of successful rows is found, embodiments are able to provide assurance that no side effects (i.e., code or operations triggered by saving of a data to a particular location) have been executed on behalf of any of the failed rows (side effects from custom PL/SOQL code included) by deferring execution of triggers until an entire set of rows can be saved and committed.

Claims

1. A computerized method in a database system having a processor and a memory therein, the method for providing fault recovery during database system operations, wherein the method comprises:

processing a set of rows to be committed to the database system;

detecting a fault while processing the set of rows to committed to the database system, wherein detecting the fault includes identifying at least one side effect in at least one of the rows in the set of rows, the side effect corresponding to code or operations triggered by saving data to a particular location within the database system, the code or operations having been executed on behalf of failed rows associated with the fault detected;

rolling back resource allocations associated with the processing of the set of rows to be committed to the database system;

removing one or more rows associated with the fault during the processing of the set of rows to be committed to the database system, wherein the one or more rows are removed from the set of rows to be committed to the database system until a resulting subset of the rows to be committed to the database system is able to be processed without fault; and

committing the resulting subset of the rows to the database system.

2. The method of claim 1, wherein detecting a fault includes:

detecting at least one of a pre-operation trigger, a post-operation trigger, a code snippet.

3. The method of claim 1, wherein rolling back resource allocations includes:

rolling back governor limits placed upon code executing on behalf of rows that are being rolled back.

4. A non-transitory machine-readable storage medium having instructions stored thereon for providing fault recovery that, when executed by one or more processors in a database system, the instructions cause the database system perform operations comprising:

processing a set of rows to be committed to the database system;

detecting a fault while processing the set of rows to committed to the database system, wherein detecting the fault includes identifying at least one side effect in at least one of the rows in the set of rows, the side effect corresponding to code or operations triggered by saving data to a particular location within the database system, the code or operations having been executed on behalf of failed rows associated with the fault detected;

rolling back resource allocations associated with the processing of the set of rows to be committed to the database system;

removing one or more rows associated with the fault during the processing of the set of rows to be committed to the database system, wherein the one or more rows are removed from the set of rows to be committed to the database system until a resulting subset of the rows to be committed to the database system is able to be processed without fault; and

committing the resulting subset of the rows to the database system.

5. The non-transitory machine-readable storage medium of claim 4, wherein detecting a fault includes:

detecting at least one of a pre-operation trigger, a post-operation trigger, a code snippet.

6. The non-transitory machine-readable storage medium of claim 4, wherein rolling back resource allocations includes:

rolling back governor limits placed upon code executing on behalf of rows that are being rolled back.

7. A database system for providing fault recovery occurring during database system operations, wherein the database system comprises:

a processor;

a memory; and

one or more stored sequences of instructions which, when executed by the processor, cause the database system to carry out operations comprising;

processing a set of rows to be committed to the database system;

detecting a fault while processing the set of rows to committed to the database system, wherein detecting the fault includes identifying at least one side effect in at least one of the rows in the set of rows, the side effect corresponding to code or operations triggered by saving data to a particular location within the database system, the code or operations having been executed on behalf of failed rows associated with the fault detected;

rolling back resource allocations associated with the processing of the set of rows to be committed to the database system;

removing one or more rows associated with the fault during the processing of the set of rows to be committed to the database system, wherein the one or more rows are removed from the set of rows to be committed to the database system until a resulting subset of the rows to be committed to the database system is able to be processed without fault; and

committing the resulting subset of the rows to the database system.