|
Probably not, because TCP provides packet recovery: http://en.wikipedia.org/wiki/Packet_loss#Packet_recovery So, there is no hand-shake on database level?
(14 Feb '12, 02:57)
Martin
Replies hidden
If commit is succesful than you get succesfull return code. If tcp connection is broken while you transmit packet with commit than you get connection error (tcp garanee it). But may be will be interesting for you distributed transaction/two phase commit technology?
(14 Feb '12, 03:53)
AlexeyK77
I am wondering if a situation is possible there the client sends the commit but server never receives it and client waits indefinetly to receive the handshake.
(14 Feb '12, 04:48)
Martin
The possible answers are wayyy beyond my network knowledge, but the effect of the LivenessTimeout would come into play here, methinks.
(14 Feb '12, 05:03)
Volker Barth
Comment Text Removed
|
|
It won't recognize this particular failure, because TCP will provide packet recovery as Breck has mentioned. Assuming TCP isn't able to recover and resend the packet, the client libraries should return a communication error (-85): Other failures for a commit should also be surfaced as an error. Ultimately, if the call making a commit returns without an error code, the commit should succeed. |
