[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #27823] SQLClient drops connections without sending notificatio

From: Robert J. Slover
Subject: Re: [bug #27823] SQLClient drops connections without sending notifications
Date: Tue, 27 Oct 2009 15:42:08 -0400


At work, one part of our application is used to 'scan' data gathered from various devices, normalizes it, and inserts it into the database as measurements. This is very performance-critical, and for a very large percentage of the cases, we are only ever inserting rows (new measurements). However, on occasion we need to 'reprocess' the data that was originally gathered (for instance, if the model used to normalize the data has been modified to correct an error). In this case, the same measurement rows will be inserted, albeit they may contain slightly different information. This component of the application has no knowledge of whether it is processing data for the first time or reprocessing it (and no need to know, either). It first attempts to insert a row and if that fails due to a duplicate key constraint violation, it will do an update instead. The overhead of querying the database first to see if the record is already there would in most cases be completely wasted, and in the rarer case would not save anything over simply attempting the insert in the first place. This of course uses straight C and ODBC, but the principle is the sameā€¦if the ODBC drivers forced a disconnect on every constraint violation, we would have significantly worse performance, and would have to opt for the generally slower approach of querying first, since we can only commit a group of measurements for an interval on success of the entire scan (it either all goes in or none of it does).

In summary, I would agree with the OP that disconnecting due to an error is generally the wrong thing to do. If SQL*Plus did that, I would refuse to use it. This behavior is akin to library code calling exit(1), etc., instead of returning an error condition that can possibly be handled.


On Oct 27, 2009, at 8:59 AM, Richard Frith-Macdonald wrote:

Update of bug #27823 (project gnustep):

                 Status:                    None => Fixed
            Open/Closed:                    Open => In Test


Follow-up Comment #1:

I went through and checked that backends don't call the internal
connect/disconnect methods when they should be calling the public versions
(which are responsible for sending notifications).
This should be working in svn trunk now.

Anyway, it seems rather unfriendly (and performance-hostile) to drop
the connection just because there was an error.

I'm not sure I can agree with that ... if you are causing errors frequently enough for dropping the connection to be a big performance issue then there's
probably something wrong with the way you are doing things.

Dropping the connection is a safety feature, to ensure that there is no chance of a connection being left in any sort of confused state by some unanticipated error ... but I wouldn't mind a patch to allow a connection to
attempt to recover gracefully as an option instead.


Reply to this item at:


 Message sent via/by Savannah

Bug-gnustep mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]