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

[Robert J. Slover]

Richard,

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.

--Robert

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:
>
>  <http://savannah.gnu.org/bugs/?27823>
>
> _______________________________________________
>  Message sent via/by Savannah
>  http://savannah.gnu.org/
>
>
>
> _______________________________________________
> Bug-gnustep mailing list
> Bug-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-gnustep