On 2016/10/04 16:10, Ashutosh Bapat wrote:
>>> Heuristics can not become the default behavior. A user should be given
>>> an option to choose a heuristic, and he should be aware of the
>>> pitfalls when using this heuristic. I guess, first, we need to get a
>>> solution which ensures that the transaction gets committed on all the
>>> servers or is rolled back on all the foreign servers involved. AFAIR,
>>> my patch did that. Once we have that kind of solution, we can think
>>> about heuristics.
>>
>> I meant that we could determine it heuristically only when remote server
>> crashed in 2nd phase of 2PC.
>> For example, what does the local server returns to client when no one remote
>> server returns OK to local server in 2nd phase of 2PC for more than
>> statement_timeout seconds? Ok or error?
>>
>
> The local server doesn't wait for the completion of the second phase
> to finish the currently running statement. Once all the foreign
> servers have responded to PREPARE request in the first phase, the
> local server responds to the client. Am I missing something?
PREPARE sent to foreign servers involved in a given transaction is
*transparent* to the user who started the transaction, no? That is, user
just says COMMIT and if it is found that there are multiple servers
involved in the transaction, it must be handled using two-phase commit
protocol *behind the scenes*. So the aforementioned COMMIT should not
return to the client until after the above two-phase commit processing has
finished.
Or are you and Sawada-san talking about the case where the user issued
PREPARE and not COMMIT?
Thanks,
Amit