Re: patch: streaming of bytea parameter values

Поиск
Список
Период
Сортировка
Искать
От
Kris Jurka
Тема
Re: patch: streaming of bytea parameter values
Дата
в 18:24:09
Msg-id
Pine.BSO.4.56.0405231441080.5428@leary.csoft.net
Ответ на
Список
Дерево обсуждения
patch: streaming of bytea parameter values Oliver Jowett <oliver@opencloud.com>
Re: patch: streaming of bytea parameter values Oliver Jowett <oliver@opencloud.com>
Re: patch: streaming of bytea parameter values Kris Jurka <books@ejurka.com>
Re: patch: streaming of bytea parameter values Oliver Jowett <oliver@opencloud.com>
Re: patch: streaming of bytea parameter values Kris Jurka <books@ejurka.com>


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
В списке pgsql-jdbc по дате отправления
От: Kris Jurka
Дата:
От: Oliver Jowett
Дата:
FAQ