search

atomikos / transactions-essentials

Development repository for next major release of
https://www.atomikos.com/Main/TransactionsEssentials
Other
461 stars 139 forks source link

orphandetectException in microservice transaction with 4-level-Diamond-diagram #124

Closed beanww closed 2 years ago

beanww commented 4 years ago

[orphandetectEx-4levelDiamondTrans.log](https://github.com/atomikos/transactions-essentials/files/5185845/orphandetectEx-4levelDiamondTrans.log)

In this scenario, X(root node) -->A--->B--->D ------------------------------------ |--->C-----^(D was invoke twice by B,C)

orphan detect exception was thrown on D-preparing, please check the log, any help?thanks!

GuyPardon commented 4 years ago

Can you please try with the latest 5.0.8?

Thanks

beanww commented 4 years ago

Hi GuyPardon, I had tested 5.0.8, and the same error occured. But I think I have found the reason: In class DefaultExporting(Importing)TransactionManager, something should to do to make sure extent's participant.direct value be right.

In attachement logfile, you can find all direct=true in extent info returned by server side, even if the participant is not direct, eg. x-->a-->b-->d, extent returned by a to x list participants b/c/d with direct=true, should change to false, only keep a.direct=true.

0903 16:06:38.494|EBUG|a|-d-0[share]-thread-1|DefaultImportingTransactionManager.logDebug(32)| Returning extent: version=2019,parent=tm-x159912039585000001,uri=http://localhost:28004/atomikos/tm-x159912039585000001/tm-d159912039727600002,responseCount=2,direct=true,uri=http://localhost:28002/atomikos/tm-x159912039585000001/tm-b159912039684300002,responseCount=1,direct=true,uri=http://localhost:28004/atomikos/tm-x159912039585000001/tm-d159912039727600002,responseCount=2,direct=true,uri=http://localhost:28003/atomikos/tm-x159912039585000001/tm-c159912039784200002,responseCount=1,direct=true,uri=http://localhost:28001/atomikos/tm-x159912039585000001/tm-a159912039643200002,responseCount=1,direct=true|

I forced change the extent String in my server-response interceptor method to test this solution, it works.

And this fix can also fix a problem--multi times 2PC rest request:

Because all cascade participant is direct=true, so I found root-cordinator will send prepare/commit rest request to all descendant(NOT direct descendant), and so does the other child cordinator, so if A->B->C, in 2PC, A will 2PC B/C, and then B will 2PC C, so c will receive 2PC rest request twice..

With right direct setting, this issue also can be fix, please check this issue, Thanks!

GuyPardon commented 4 years ago

Thank you, we will have a look!

GuyPardon commented 2 years ago

This should be fixed in the upcoming 5.0.9 and 5.0.109