optimize: reduce the number of lock conflict exception

[ggndnn]

Ⅰ. Describe what this PR did

Move lock retry loop into ConnectionProxy.commit, that the number of LockKeyConflict can be significantly reduced whether auto-commit is true or false. Related issue #1438.

Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)?

Ⅳ. Describe how to verify it

Ⅴ. Special notes for reviews

[codecov-io]

Codecov Report

Merging #1469 into develop will increase coverage by 0.47%.
The diff coverage is 48.78%.

@@              Coverage Diff              @@
##             develop    #1469      +/-   ##
=============================================
+ Coverage      46.78%   47.25%   +0.47%     
- Complexity      1730     1757      +27     
=============================================
  Files            353      353              
  Lines          12941    12967      +26     
  Branches        1618     1620       +2     
=============================================
+ Hits            6054     6128      +74     
+ Misses          6236     6178      -58     
- Partials         651      661      +10

Impacted Files	Coverage Δ	Complexity Δ
...ava/io/seata/core/constants/ConfigurationKeys.java	0% <ø> (ø)	0 <0> (ø)	⬇️
...n/java/io/seata/rm/datasource/ConnectionProxy.java	22.5% <44.44%> (+13.98%)	10 <1> (+6)	⬆️
...ta/rm/datasource/exec/AbstractDMLBaseExecutor.java	71.87% <57.14%> (+62.5%)	6 <1> (+4)	⬆️
.../rm/datasource/exec/BaseTransactionalExecutor.java	18.26% <0%> (+0.86%)	7% <0%> (+1%)	⬆️
...o/seata/rm/datasource/AbstractConnectionProxy.java	13.09% <0%> (+1.19%)	6% <0%> (+1%)	⬆️
...a/rm/datasource/exec/LockWaitTimeoutException.java	33.33% <0%> (+33.33%)	1% <0%> (+1%)	⬆️
...java/io/seata/rm/datasource/ConnectionContext.java	46.66% <0%> (+33.33%)	11% <0%> (+8%)	⬆️
.../seata/rm/datasource/exec/LockRetryController.java	92.3% <0%> (+92.3%)	4% <0%> (+4%)	⬆️
... and 1 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d334f85...14c9f3a. Read the comment docs.

[slievrly]

@ggndnn I am very interested because we always have different ideas. When a LockConflictException occurs, it indicates that there are other distributed transactions that are executing that hold the same data primary key. We define the current distributed transaction as A and another distributed transaction as B. A holds the database lock and wants to get the global lock, and B holds the global lock. If at this point B wants to rollback this data in the second phase of the distributed transaction, it will try to acquire the database lock. According to your code, A will hold the database lock for a longer time. At this time, B may trigger the lock wait timeout exception and perform a rollback retry. We need to evaluate this.

[ggndnn]

@slievrly It's indeed interesting to have discussions with you, the atmosphere here is good， different ideas always make things more clear. Thank you.

Before I make this PR, I referred to seata document in wiki, e.g.

I think tx2 is A which you just mentioned and tx1 is B. I understand your worries. I also agree that we should make quick fail to avoid waiting too much. But rollback is not what we preferred, we prefer commit, according to issue 1438, we got exception immediately, may be just a moment we can get a success transaction. I think this PR is more in line with the figure in wiki. Is that a formal design?

I agree that we should evaluate this. What can we do with this PR?

[slievrly]

@ggndnn I am very happy to discuss this with you. I understand what you mean above. By the way, is it appropriate for us to communicate through DingTalk?

[ggndnn]

@slievrly I joined DingTalk group.

[slievrly]

@ggndnn Do you want to add a switch here as we communicate?

[ggndnn]

@slievrly Ok, I'll add a switch.

[ggndnn]

@slievrly I added a switch. Please have a look whether it's appropriate.

[slievrly]

LGTM, but the code is not so easy to understand.

[slievrly]

just used for LOCK_RETRY_POLICY_BRANCH_ROLLBACK_ON_CONFLICT=false

[ggndnn]

Should it be okay to do ConnectionProxy#rollback in both cases?

[xingfudeshi]

LGTM.