Optimize Coordinator#getStateForGroupCommit() by first looking up the coordinator table with parent transaction ID

[komamitsu]

Description

The current implementation of Coordinator.getStateForGroupCommit() checks transaction states that were stored with the Group Commit feature enabled in the following order:

1. First, it tries to find a record whose tx_id is the full transaction ID, returning the state if it's found. This record type is created when a transaction is delayed and committed individually.
2. Next, it tris to find a record whose tx_id is the parent transaction ID, returning the state if it's found and the tx_sub_ids contains the child transaction ID. This record type is created when a transaction gets commit-ready in time and group-committed.

This order is optimized for lazy-recovery, which is more likely to happen if the commit timing is delayed after PREPARE record is created. However, basically lazy-recovery doesn't happen so often.

We may create a new system that frequently looks up the coordinator table in the future. In that case, it might need to prioritize first finding group-committed transactions, not just delayed individually committed transaction. The current order doesn't fit this scenario.

This PR changes the lookup order to prioritize group-committed transactions first.

Related issues and/or PRs

None

Changes made

• Change the order of GET operations with full transaction ID and parent ID in Coordinator#getStateForGroupCommit().
• Update the unit test along with the change.

Checklist

The following is a best-effort checklist. If any items in this checklist are not applicable to this PR or are dependent on other, unmerged PRs, please still mark the checkboxes after you have read and understood each item.

• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation to reflect the changes.
• Any remaining open issues linked to this PR are documented and up-to-date (Jira, GitHub, etc.).
• Tests (unit, integration, etc.) have been added for the changes.
• My changes generate no new warnings.
• Any dependent changes in other PRs have been merged and published.

Additional notes (optional)

None

Release notes

N/A

[brfrn169]

LGTM! Thank you!

[Torch3333]

LGTM, thank you!

[feeblefakie]

The code looks good!
I left a suggestion on the comment.
PTAL!

[feeblefakie]

The comment is a bit hard to follow to me, so can it be something like this?
Please also verify if it is correct.

The current implementation is optimized for a case where most transactions are group-committed.
Specifically, Coordinator first checks a transaction state by using a parent ID with one read operation.
If it cannot find it, which means the transaction is delayed and not included in a group, it will issue an additional read operation by using the full ID.

[komamitsu]

@feeblefakie Thanks! It seems better.

How about the following version revised based on your suggestion?

The current implementation is optimized for cases where most transactions are group-committed. It first looks up a transaction state by the parent ID with a single read operation. If no matching transaction state is found (i.e., the transaction was delayed and committed individually), it issues an additional read operation using the full ID.

[komamitsu]

Updated the comment in 1b62d3c

[feeblefakie]

It looks good!
Just one thing. Let's use consistent wording (using xxx ID).

The current implementation is optimized for cases where most transactions are group-committed. It first looks up a transaction state using the parent ID with a single read operation. If no matching transaction state is found (i.e., the transaction was delayed and committed individually), it issues an additional read operation using the full ID.

[komamitsu]

Thanks! Fixed it in 6e3ece2.

[feeblefakie]

Left a comment on the Javadoc comment, other than that LGTM! Thank you!