>>>>> "OB" == Oyvind Bakksjo <[EMAIL PROTECTED]> writes:
OB> I would not say they perform exactly the same operation. The one on
OB> the server side stops the processing, causing statement rollback. The
OB> one on the client side just returns control to the application. I
OB> would think the application would be interested in knowing the
OB> transaction state after a statement timeout. Therefore, the server
OB> should time out the statement and throw an exception to the
OB> client. Otherwise, it might be that the statement successfully
OB> completes execution on the server side, but is cancelled on the client
OB> side before the result is returned. In this case, the client would get
OB> an exception, wrongfully indicating that the statement processing was
OB> cancelled when it in fact was not. This may result in erroneous client
OB> behaviour later, and thus, unexpected inconsistencies in the database
OB> (at the application semantic level). Alternatively, the client must
OB> use a different exception code on timeout, implying that the outcome
OB> of the last statement execution is unknown.
I agree with Øyvind that we need to distinguish between loosing
contact with the server and a query timing out. If the contact is
lost, the client will not be able to know whether the request
succeeded or not and have to take actions if it needs to determine
what has happened. If the query times out, the server will guarantee
that the statement is rolled back.
In other words, I do not think we should use the query timeout to
determine whether the client is still able to contact the server. A
separate keep-alive mechanism should be used for that purpose.
--
Øystein
