On Sun, 23 May 2004, Oliver Jowett wrote:
> Kris Jurka wrote:
> > On Sun, 23 May 2004, Oliver Jowett wrote:
> >>
> >>I don't see what isn't cleaned up by closing the connection. It seems
> >>the simplest and safest way of handling this sort of error.
> >
> This is a bit different in that we can always detect it. You never end
> up with a hosed connection that the driver will try to continue using.
>
> Being user-friendly when dealing with application errors is nice
> behaviour to have, but it *is* a separate issue..
Separate from what, correctness? We both agree that a short stream or
IOException is an error, but I'm not advocating the JDBC equivalent of
System.exit() as a viable solution. What makes it OK for this
particular error to destroy a Connection while no other application level
error can?
>
> > This is more of a general problem with the JDBC driver
> > in that if it throws an Exception itself it does not require a rollback
> > while server generated errors do. Perhaps this should be added to the
> > drivers query issuing/commit logic to refuse to proceed if the driver has
> > thrown an error.
>
> If you're talking about all the exceptions that can ever be thrown by
> the driver, it sounds like unnecessary complexity to me,
>
> It makes sense for exceptions thrown during query execution though, Are
> there currently any cases where the driver can throw an exception from
> query execution without invalidating the current transaction?
>
I am unsure what you mean by "query execution." From a user's perspective
the moment they say PreparedStatement.execute() query execution has begun
and in that case the Exception that comes to mind is the check to make
sure all parameters of a PreparedStatement have been set. See
QueryExecute.sendQueryV3. From a driver perspective query execution
begins when it issues pgStream.SendChar('Q') or similar and I believe the
only Exception that should be thrown there in the current code is an
IOException on the stream which is fatal to the connection in any case.
Kris Jurka
