Re: [Firebird-devel] Commit (un)certainity

2022-01-11 Thread Leyne, Sean



> Mark Rotteveel wrote 06.01.2022 13:06:
> > BTW: I think in most cases you should be able to infer from the socket
> > error if the problem occurred on sending or on reading data (at least,
> > when using blocking socket reads/writes, not sure about non-blocking).
> 
>It is not true:
> 
> https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-
> winsock2-send
> 
> > The successful completion of a send function does not indicate that the
> data was successfully delivered and received to the recipient. This function
> only indicates the data was successfully sent.
> 
> https://linux.die.net/man/3/send
> 
> > Successful completion of a call to send() does not guarantee delivery of the
> message. A return value of -1 indicates only locally-detected errors.

Not being very familiar with client API functionality, I need to ask.

There is no ACK response sent to the client when a message/request is received 
by the server for non-immediate response (ie. "execute SQL" vs. "get version")?


Sean



Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Commit (un)certainity

2022-01-09 Thread Ann Harrison
>It is documented that successful return from function send() for TCP
> doesn't
> mean successful delivery of data to the target host, mere put them into
> socket
> buffer.
>If op_commit is sent but network error appear during waiting for
> response
> there can be two cases:
>1) op_commit packet is lost on its way to server;
>2) op_response is lost on its way to client.
>
>In the first case the transaction on server is rolled back in the
> latter -
> committed successfully.
>
>Is there a way to handle such situation? Using of two round-trips
> cannot
> solve the problem, only shift point of uncertainty.
>

Two phase commit does solve the problem, at considerable expense.

Cheers,

Ann
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Commit (un)certainity

2022-01-06 Thread Dimitry Sibiryakov

Mark Rotteveel wrote 06.01.2022 13:06:
BTW: I think in most cases you should be able to infer from the socket error if 
the problem occurred on sending or on reading data (at least, when using 
blocking socket reads/writes, not sure about non-blocking).


  It is not true:

https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-send


The successful completion of a send function does not indicate that the data 
was successfully delivered and received to the recipient. This function only 
indicates the data was successfully sent.


https://linux.die.net/man/3/send

Successful completion of a call to send() does not guarantee delivery of the message. A return value of -1 indicates only locally-detected errors. 




--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Commit (un)certainity

2022-01-06 Thread Mark Rotteveel

On 2022-01-05 21:48, Jiří Činčura wrote:

   Yes. You probably have the same problem in your provider, no?


The problem exists there. Same as with fbclient. But I don't
explicitly solve it, application developer is responsible for handling
such scenario (if ever).


I agree. If the application developer thinks this is a problem, they 
should switch to using 2-phase commits and having a scavenger to handle 
limbo transactions.


BTW: I think in most cases you should be able to infer from the socket 
error if the problem occurred on sending or on reading data (at least, 
when using blocking socket reads/writes, not sure about non-blocking).


Mark


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Commit (un)certainity

2022-01-05 Thread Jiří Činčura
>Yes. You probably have the same problem in your provider, no?

The problem exists there. Same as with fbclient. But I don't explicitly solve 
it, application developer is responsible for handling such scenario (if ever).

-- 
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/



Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Commit (un)certainity

2022-01-05 Thread Adriano dos Santos Fernandes
Em qua., 5 de jan. de 2022 17:14, Dimitry Sibiryakov 
escreveu:

> Jiří Činčura wrote 05.01.2022 19:44:
> > You're probably thinking about something in client library?
>
>Yes. You probably have the same problem in your provider, no?


If no response or network error is returned, application will be stuck,
will receive the error or will receive a timeout error.

It looks like an application thing, not a driver thing.


Adriano
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Commit (un)certainity

2022-01-05 Thread Dimitry Sibiryakov

Jiří Činčura wrote 05.01.2022 19:44:

You're probably thinking about something in client library?


  Yes. You probably have the same problem in your provider, no?

--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Commit (un)certainity

2022-01-05 Thread Vlad Khorsun

05.01.2022 15:03, Dimitry Sibiryakov wrote:

   Hello All.

   It is documented that successful return from function send() for TCP doesn't mean successful delivery of data to the target host, 
mere put them into socket buffer.

   If op_commit is sent but network error appear during waiting for response 
there can be two cases:
   1) op_commit packet is lost on its way to server;
   2) op_response is lost on its way to client.

   In the first case the transaction on server is rolled back in the latter - 
committed successfully.

   Is there a way to handle such situation? 


  2PC protocol was developed for this kind of problems.


   Using of two round-trips cannot solve the problem, only shift point of 
uncertainty.


  2PC allows to know trasaction state and fix half-done commit.

Regards,
Vlad


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Commit (un)certainity

2022-01-05 Thread Jiří Činčura
One way to handle this is via manual inserts (and deletes) in a dedicated 
table. Something like:

1. Insert a row into the table at the beginning of each transaction.
2. If the connection fails during the commit, check for the presence of the 
corresponding row in the database.
- If the row is present, continue normally, as the transaction was committed 
successfully
- If the row is absent, use an execution strategy to retry the current 
operation.
3. If the commit is successful, delete the corresponding row to avoid the 
growth of the table.

But this needs support on application level. You're probably thinking about 
something in client library?

-- 
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


[Firebird-devel] Commit (un)certainity

2022-01-05 Thread Dimitry Sibiryakov

  Hello All.

  It is documented that successful return from function send() for TCP doesn't 
mean successful delivery of data to the target host, mere put them into socket 
buffer.
  If op_commit is sent but network error appear during waiting for response 
there can be two cases:

  1) op_commit packet is lost on its way to server;
  2) op_response is lost on its way to client.

  In the first case the transaction on server is rolled back in the latter - 
committed successfully.


  Is there a way to handle such situation? Using of two round-trips cannot 
solve the problem, only shift point of uncertainty.


--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


[Firebird-devel] Commit (un)certainity

2022-01-05 Thread Dimitry Sibiryakov

  Hello All.

  It is documented that successful return from function send() for TCP doesn't 
mean successful delivery of data to the target host, mere put them into socket 
buffer.
  If op_commit is sent but network error appear during waiting for response 
there can be two cases:

  1) op_commit packet is lost on its way to server;
  2) op_response is lost on its way to client.

  In the first case the transaction on server is rolled back in the latter - 
committed successfully.


  Is there a way to handle such situation? Using of two round-trips cannot 
solve the problem, only shift point of uncertainty.


--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel