Fixes #
For transaction stream load at at-least-once mode, only load phase is executed asynchronously in a thread pool whose size is controlled by sink.io.thread-count , but the prepare/commit phase is executed in the single thread used for schedule, and it can block the schedule thread if prepare/commit takes much time. For multiple tables case, this can prevent to schedule other tables to load/prepare/commit, and lead to performance issue. So we make the prepare/commit also asynchronous.
Problem Summary(Required) ：
Checklist:
[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)
[ ] I have added documentation for my new feature or new function
What type of PR is this：
Which issues of this PR fixes ：
Fixes # For transaction stream load at at-least-once mode, only load phase is executed asynchronously in a thread pool whose size is controlled by
sink.io.thread-count, but the prepare/commit phase is executed in the single thread used for schedule, and it can block the schedule thread if prepare/commit takes much time. For multiple tables case, this can prevent to schedule other tables to load/prepare/commit, and lead to performance issue. So we make the prepare/commit also asynchronous.Problem Summary(Required) ：
Checklist: