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
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
