Provide API for retrieving a log of all executed/failed operations of a transaction cycle


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




Emmanuel Bernard
June 30, 2014, 11:25 AM

A few ideas that popped up:

The error handling is called upon failure at flush time.
The error handling needs to be able to say what has worked and what has failed (per flush, maybe per transaction scope)
If transaction scope, verify that WildFly can start and call Synchonized on transactions where no tx resources end up being added. => Gunnar swears on his life that it works already.
The error handling needs to be able to say CONTINUE the other operations or ABORT.
The error handling code should be passed both globally and per operation ( OgmSession.useErrorHandler(...) )
Offer high level operations like "undo" automatically already applied changes, pass a set of tuple operations and apply them.
Gunnar proposes to expose the GridDialect but I think that's a too low level.
Express whether the error is an optimistic error or not (version checking is done in the persister I think.
The error handling code can raise an exception that bubbles up

Use cases:

  • upon error, I want to get an exception in the application

    • That means try { .flush() } catch {}

  • upon error, user will retry with different values until success

    • offer ability to read the "old value"

    • offer ability to apply a different set of changes to a tuple

  • upon error, rollback currently done changes

    • offer a high level undo operations (automatic)

    • this is not transactional so new data might have been read

  • upon failure, ignore and keep going

    • requires the CONTINUE

  • upon optimistic locking exception, undo all and raise exception

    • undo operations

    • raise exception for bubble up and business handling

Gunnar Morling
February 25, 2015, 11:38 AM

, I tried to compile a list of use cases to be supported from your earlier comment and yesterday's IRC discussion, updated the issue description with that. Is there anything missing from your point? I think if we had something which helps users to address 1.1 and 2.1 that'd already be a very good first step.

Gunnar Morling
February 25, 2015, 12:10 PM

> About Operation, it is more that this is tuple based and the user thinks entity.

My reasoning is that the tuple-like represention is closer the persistent data in the store, e.g. with respect to data types, column names etc. When e.g. getting a log file with changes that have been applied and need to be revised, this form may be more suitable than the more abstract entity-based representation; E.g. if I need to manually create a statement for compensating a certain change.

Sanne Grinovero
March 5, 2015, 7:04 PM
Gunnar Morling
March 12, 2015, 12:51 PM

Created follow-up issues for remaining tasks and ideas developed during PR review.


Gunnar Morling


Gunnar Morling



Feedback Requested


Feedback Requested By




Suitable for new contributors


Pull Request







Fix versions