currently, we integrated with saga using graph based engine.
it need us to collect all participated actual SQL, then submit to saga actuator in commit/rollback phase. if application crashed before invoking saga actuator, undo log of branch transaction SQL will not be saved, so recovery thread will not be executed correctly.
it's better that encapsulating every actual SQL as a saga task, then submit to saga actuator realtime instead of batch processing all the SQLs at commit/rollback phase. this architecture will make the boundary more clear between shardingsphre and saga, currently we have done some additional work for integrating saga.
currently, we integrated with saga using graph based engine.
it need us to collect all participated actual SQL, then submit to saga actuator in commit/rollback phase. if application crashed before invoking saga actuator, undo log of branch transaction SQL will not be saved, so recovery thread will not be executed correctly.
it's better that encapsulating every actual SQL as a saga task, then submit to saga actuator realtime instead of batch processing all the SQLs at commit/rollback phase. this architecture will make the boundary more clear between shardingsphre and saga, currently we have done some additional work for integrating saga.