|
|
|
|
|
|
When working with a non-transactional stores, there should be a way to find out about the executed and failed grid dialect operations of a transaction cycle. This allows to take appropriate action such as performing compensating operations, re-try the failed operations etc.
Use cases:
As a user of OGM, upon an exception during flush(),
* UC-1.1: I want to *log* all operations applied so far and *abort* the processing of the flush cycle (/)
Example: Create a file with applied changes, and let someone manually take the required actions
* UC-2.1: I want to *skip* the failed operation for certain exception types and *continue* further processing of the flush cycle (/)
Example: Ignore a duplicted record during importing a list of orders
* UC-2.1.1: I want to skip the failed operation for certain exception types and entity types and continue further processing of the flush cycle (/)
Example: Ignore a duplicated order record but not a duplicated customer record
* UC-3.1: I want *compensate* all operations applied so far and abort the processing of the flush cycle
* UC-3.1.1: I want to execute *custom compensation actions*
Example:
* UC-3.1.2: I want to execute *automatically determined compensation actions* (e.g. a delete for an insert, an insert/update to restore the previous state for a delete/update)
Example:
* UC-4.1: I want to work with *different means of error handling*, depending on the "business case" I am in; e.g. I might want to ignore an exception at one time but try to compensate previously applied changes at another time (NOTE: are entity types enough as distinguishing criteria, see UC-2.1.1?)
|
|
|
|
|
|
