Issue 7638 - back-sql: Handle connection loss
Summary: back-sql: Handle connection loss
Status: VERIFIED SUSPENDED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: backends (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-07 09:35 UTC by pierre@reactos.org
Modified: 2021-04-01 16:27 UTC (History)
0 users

See Also:


Attachments
back-sql-handle-connection-lost.patch (12.65 KB, patch)
2020-03-20 17:29 UTC, Quanah Gibson-Mount
Details

Note You need to log in before you can comment on or make changes to this issue.
Description pierre@reactos.org 2013-07-07 09:35:08 UTC
Full_Name: Pierre Schweitzer
Version: HEAD
OS: Ubuntu
URL: http://fc.isima.fr/~schweitz/schweitz/0001-In-the-SQL-backend-add-code-to-handle-a-connection-los.txt
Submission from: (NULL) (90.27.237.49)


Hi,

here is a patch to handle a possible connection loss to DBMS for the SQL
backend. Right now, in case of connection loss, slapd just denied any entry
lookup with an error 80 (backend error).
With this patch, before preparing any req on the given connection handle, the
backend will first try to check whether the connection is active by issue a
dummy query. In case it's not, it will close the previous connection and open a
new one. And then, will prepare the req on the connection link.

I made this choice of developement because, preparing statement, executing it
and then, only looking whether it fails to re-submit would have been more
complex, since it would have required to start over the whole process for the
query (statement preparation and such) while preparation & execution aren't not
in the same function.

This patch has been tested and validated in production on the ReactOS Foundation
infrastructure.

The attached patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following patch(es) were
developed by Pierre Schweitzer (pierre@reactos.org). I have not assigned rights
and/or interest in this work to any party.

I, Pierre Schweitzer, hereby place the following modifications to OpenLDAP
Software (and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.

Regards,
Pierre
Comment 1 Michael Ströder 2013-07-07 12:33:00 UTC
pierre@reactos.org wrote:
> With this patch, before preparing any req on the given connection handle, the
> backend will first try to check whether the connection is active by issue a
> dummy query. In case it's not, it will close the previous connection and open a
> new one. And then, will prepare the req on the connection link.
>
> I made this choice of developement because, preparing statement, executing it
> and then, only looking whether it fails to re-submit would have been more
> complex, since it would have required to start over the whole process for the
> query (statement preparation and such) while preparation & execution aren't not
> in the same function.

Hmm, so there's an extra dummy query for each real query. If the SQL DB is 
connected over network this means a synchronous extra round trip for each query.

Ciao, Michael.


Comment 2 pierre@reactos.org 2013-07-08 17:29:42 UTC
Unfortunately, I don't see any other solution. I browsed everything I 
could in ODBC doc, in order to be able to query link status, but there's 
no way.

And the other solution to redo the whole statement in case of failure 
would be even more complex and would require too many code rewrites due 
to a complete logic change. So, it seems to me to be the intermediate 
solution.

The overhead being limited on "decent" connection.

Regards,

On 07/07/2013 14:33, Michael Ströder wrote:
> pierre@reactos.org wrote:
>> With this patch, before preparing any req on the given connection 
>> handle, the
>> backend will first try to check whether the connection is active by 
>> issue a
>> dummy query. In case it's not, it will close the previous connection 
>> and open a
>> new one. And then, will prepare the req on the connection link.
>>
>> I made this choice of developement because, preparing statement, 
>> executing it
>> and then, only looking whether it fails to re-submit would have been 
>> more
>> complex, since it would have required to start over the whole process 
>> for the
>> query (statement preparation and such) while preparation & execution 
>> aren't not
>> in the same function.
>
> Hmm, so there's an extra dummy query for each real query. If the SQL 
> DB is connected over network this means a synchronous extra round trip 
> for each query.
>
> Ciao, Michael.
>
>


-- 
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation


Comment 3 Quanah Gibson-Mount 2020-03-20 17:29:13 UTC
Created attachment 629 [details]
back-sql-handle-connection-lost.patch