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