Two or three things you know about a business from a real scene

Real-world scenario: in the company-to-consumer app testing process, the front-end test found a bug--from the virtual wallet transfer to the successful collection, the virtual wallet amount no deduction
1. The misunderstanding of cognition one: the resources in the transaction can be rollback.

The problem code logic is as follows

// Pseudo Code begin translation // Call the Payment interface boolean callresult= remote.transf (...); if (callresult) {   // operations Local Database   boolean payresult= local.pay (...);    if (Payresult)   {      commit;   }    Else    {     rollback;   }} Else {  Rollback}end translation

problem reason : The transfer interface does not support rollback for the caller, so this is a "pseudo transaction",
The real transaction should be whether it is a local transaction or a distributed transaction
The resources associated with any of the resource managers involved in a transaction are support for commit and rollback;

Resolution : Adjust the call order

// Pseudo Code begin translation // operation Local Database Boolean callresult = local.pay (...); if (callresult) {   // Call the Payment interface   boolean payresult= remote.transf (...);    if (Payresult)   {      commit;   }    Else    {     rollback;   }} Else {  Rollback}end translation

2. Misunderstanding two: The business is effective
Http://www.cnblogs.com/xiaoyuanding/p/3947986.html

Distributed transactions can be simplified to local transactions
Does simplifying work for local transactions?
Because the operation of deleting files is called two times, the local transaction does not work regardless of how the call order is adjusted, so the use of transactions is the same as without transaction results

Solution: Delete the file with the persistent Message Queuing post message or the timed task + message Status field, and, if unsuccessful, retry continuously until successful.

Two or three things you know about a business from a real scene