Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
2000_concepts:0800_data_processing:0200_rules_transactions [2026/08/13 00:53] – ↷ Page moved from docs:2000_concepts:0800_data_processing:0200_rules_transactions to 2000_concepts:0800_data_processing:0200_rules_transactions localdev2000_concepts:0800_data_processing:0200_rules_transactions [2026/08/13 01:10] (current) – external edit 127.0.0.1
Line 5: Line 5:
 In //**AwareIM**// data processing may occur under the following scenarios: In //**AwareIM**// data processing may occur under the following scenarios:
  
-  - An external request has been issued to the system, which triggered rule evaluation (see [[docs:2000_concepts:0800_data_processing:0100_rule_evaluation|Rule Evaluation]]). This external request may have been issued either from the User Interface or from an external software system.+  - An external request has been issued to the system, which triggered rule evaluation (see [[2000_concepts:0800_data_processing:0100_rule_evaluation|Rule Evaluation]]). This external request may have been issued either from the User Interface or from an external software system.
   - A notification has been received by //**AwareIM**//, which triggered rule evaluation.   - A notification has been received by //**AwareIM**//, which triggered rule evaluation.
-  - A timer event triggered scheduled processes to start executing (see [[docs:2000_concepts:0900_prod_feats:0400_scheduling|Scheduling]]). +  - A timer event triggered scheduled processes to start executing (see [[2000_concepts:0900_prod_feats:0400_scheduling|Scheduling]]). 
-The following section describes how //**AwareIM**// handles database transactions when processing data under the above scenarios (transactions are described in the [[docs:2000_concepts:0500_data_storage|Data Storage]] section).+The following section describes how //**AwareIM**// handles database transactions when processing data under the above scenarios (transactions are described in the [[2000_concepts:0500_data_storage|Data Storage]] section).
  
 With scenarios 1 and 3 data processing occurs within a context of a single transaction. This means that if something goes wrong all changes that have been done by any of the rules between the start of the external request (or when the scheduled process started) and the error are discarded (transaction is rolled back).  With scenarios 1 and 3 data processing occurs within a context of a single transaction. This means that if something goes wrong all changes that have been done by any of the rules between the start of the external request (or when the scheduled process started) and the error are discarded (transaction is rolled back). 
  
-What can go wrong? First of all a transaction is rolled back if any of the rules issues the ''[[ref:a_f:a:report_error|REPORT ERROR]]'' action. This action indicates an unrecoverable operation error so the current transaction is immediately rolled back and any prior changes are discarded((  Transaction is not rolled back if process failure rules are defined for a process that started rule evaluation in the first place – see [[docs:2000_concepts:0800_data_processing:0200_rules_transactions:0300_process_failure_rules|Process Failure Rules]]. )). A transaction is also rolled back in case of an internal error.+What can go wrong? First of all a transaction is rolled back if any of the rules issues the ''[[ref:a_f:a:report_error|REPORT ERROR]]'' action. This action indicates an unrecoverable operation error so the current transaction is immediately rolled back and any prior changes are discarded((  Transaction is not rolled back if process failure rules are defined for a process that started rule evaluation in the first place – see [[2000_concepts:0800_data_processing:0200_rules_transactions:0300_process_failure_rules|Process Failure Rules]]. )). A transaction is also rolled back in case of an internal error.
  
 With scenario 2 the behaviour of the system is slightly different. The rules attached to a notification event are considered to be independent and are executed within separate database transactions, so if one rule fails anywhere it does not affect other rules attached to the notification – their changes are committed provided that these changes themselves did not cause errors. With scenario 2 the behaviour of the system is slightly different. The rules attached to a notification event are considered to be independent and are executed within separate database transactions, so if one rule fails anywhere it does not affect other rules attached to the notification – their changes are committed provided that these changes themselves did not cause errors.
  
 See also: See also:
-{{simplenavi>docs:2000_concepts:0800_data_processing:0200_rules_transactions}}+{{simplenavi>.:0200_rules_transactions}}