Thread: setQueryTimeout problem !?!?!

The 8.3 JDBC driver now throws UnsupportedOperationException in
setQueryTimeout.

The specification states that the request should be ignored - not
throw an exception in this case.

The 8.1 and 8.2 drivers both ignored the request.

I think the 8.3 driver needs to be changed to work as before.

robert engels wrote:

> The specification states that the request should be ignored - not throw
> an exception in this case.

Do you have a spec reference for this?

-O

robert engels wrote:
> Here is the javadoc. The method explicitly states when it throws an
> exception:
>
>     /**
>      * Sets the number of seconds the driver will wait for a
>      * <code>Statement</code> object to execute to the given number of
> seconds.
>      * If the limit is exceeded, an <code>SQLException</code> is thrown.
>      *
>      * @param seconds the new query timeout limit in seconds; zero means
>      *        there is no limit
>      * @exception SQLException if a database access error occurs
>      *            or the condition seconds >= 0 is not satisfied
>      * @see #getQueryTimeout
>      */
>
> Even if this is not sufficient, it worked this way in the previous
> driver versions - so I guess there should be evidence the other way in
> order to change it.
>
> This is not a problem when using the 8.3 driver against an 8.3 database
> - only seems to happen with a 8.1 db (maybe 8.2???)

I did read the javadoc .. It does not say that the driver should
silently do nothing if query timeouts are unsupported.

The Java 6 javadoc is somewhat more explicit:

> Sets the number of seconds the driver will wait for a Statement object to execute to the given number of seconds. If
thelimit is exceeded, an SQLException is thrown. A JDBC driver must apply this limit to the execute, executeQuery and
executeUpdatemethods. JDBC driver implementations may also apply this limit to ResultSet methods (consult your driver
vendordocumentation for details). 

Drivers "must apply this limit", but we cannot currently do that.

The argument here is that asking the driver to do something it can't
actually do is a "database access error". So you get a SQLException if
you ask for a non-zero timeout, since that is not currently supported.

See previous discussion that prompted this change at
http://archives.postgresql.org/pgsql-jdbc/2008-01/msg00088.php

-O

>
>> Sets the number of seconds the driver will wait for a Statement
>> object to execute to the given number of seconds. If the limit is
>> exceeded, an SQLException is thrown. A JDBC driver must apply this
>> limit to the execute, executeQuery and executeUpdate methods. JDBC
>> driver implementations may also apply this limit to ResultSet
>> methods (consult your driver vendor documentation for details).
>
> Drivers "must apply this limit", but we cannot currently do that.
>
> The argument here is that asking the driver to do something it can't
> actually do is a "database access error". So you get a SQLException
> if you ask for a non-zero timeout, since that is not currently
> supported.
>
> See previous discussion that prompted this change at http://archives.postgresql.org/pgsql-jdbc/2008-01/msg00088.php

Unfortunately the argument assumes that our users are developing new
applications, not using the driver in an existing application. I think
this change should be reversed. A considerable number of people will
not be in a position to use an old driver with newer servers just to
avoid this.

Dave

Dave Cramer <pg 'at' fastcrypt.com> writes:

>> See previous discussion that prompted this change at http://archives.postgresql.org/pgsql-jdbc/2008-01/msg00088.php
>
> Unfortunately the argument assumes that our users are developing new
> applications, not using the driver in an existing application. I think
> this change should be reversed. A considerable number of people will
> not be in a position to use an old driver with newer servers just to
> avoid this.

That's really a matter of practice - how much do you afford to
break in order to fix previous problems or add features. Here,
the story is to fix an unexpected behaviour of the JDBC driver
(setQueryTimeout silently did nothing; it's *bad* to accept a
query timeout value but then not implement any timeout; a
correctly designed application will legally assume that the
queries will timeout after the configured amount of time, which
is not the case).

Last year, we have upgraded from a 7.4 server to a 8.2 server. I
can tell you that it's quite incorrect to assume that the
application, running fine on 7.4, would magically run fine on 8.2
too - actually, quite a lot of SQL queries were "broken", because
of 8.2 not accepting UPDATE and DELETE FROM with implicit SELECT
on different tables. We've had to validate our application again,
and I think it's normal.

That is to say, when the database is migrated from major
releases, the application (or the DB layer) sometimes needs
slight modifications, and it would be unreasonable deployment
practices to not validate the application again anyway.

--
Guillaume Cottenceau, MNC Mobile News Channel SA, an Alcatel-Lucent Company
Av. de la Gare 10, 1003 Lausanne, Switzerland - direct +41 21 317 50 36

The database was not being changed, just the driver.

The is fairly standard practice in the java/database world. More
recent drivers usually improve compatibility and performance.

Oracle, SQL (jtds), and others all work this way.


On Mar 18, 2008, at 8:44 AM, Guillaume Cottenceau wrote:

> Dave Cramer <pg 'at' fastcrypt.com> writes:
>
>>> See previous discussion that prompted this change at http://
>>> archives.postgresql.org/pgsql-jdbc/2008-01/msg00088.php
>>
>> Unfortunately the argument assumes that our users are developing new
>> applications, not using the driver in an existing application. I
>> think
>> this change should be reversed. A considerable number of people will
>> not be in a position to use an old driver with newer servers just to
>> avoid this.
>
> That's really a matter of practice - how much do you afford to
> break in order to fix previous problems or add features. Here,
> the story is to fix an unexpected behaviour of the JDBC driver
> (setQueryTimeout silently did nothing; it's *bad* to accept a
> query timeout value but then not implement any timeout; a
> correctly designed application will legally assume that the
> queries will timeout after the configured amount of time, which
> is not the case).
>
> Last year, we have upgraded from a 7.4 server to a 8.2 server. I
> can tell you that it's quite incorrect to assume that the
> application, running fine on 7.4, would magically run fine on 8.2
> too - actually, quite a lot of SQL queries were "broken", because
> of 8.2 not accepting UPDATE and DELETE FROM with implicit SELECT
> on different tables. We've had to validate our application again,
> and I think it's normal.
>
> That is to say, when the database is migrated from major
> releases, the application (or the DB layer) sometimes needs
> slight modifications, and it would be unreasonable deployment
> practices to not validate the application again anyway.
>
> --
> Guillaume Cottenceau, MNC Mobile News Channel SA, an Alcatel-Lucent
> Company
> Av. de la Gare 10, 1003 Lausanne, Switzerland - direct +41 21 317
> 50 36
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc

robert engels wrote:
> According to the specification
>
> If a JDBC driver does not support or only provides partial support for
> an optional
> feature, the corresponding DatabaseMetaData method must indicate the
> feature
> is not supported. Any methods for a feature that is not implemented are
> required
> to throw a SQLFeatureNotSupportedException.
>
>
> But this is not an optional exception, so I guess the real answer is the
> the driver is not JDBC 3 compliant, it would not pas the tests, and thus
> cannot be called a jdbc driver.

Indeed, we don't claim that the driver is fully JDBC3 compliant. See
http://jdbc.postgresql.org/#features

-O

On 18-Mar-08, at 9:44 AM, Guillaume Cottenceau wrote:

> Dave Cramer <pg 'at' fastcrypt.com> writes:
>
>>> See previous discussion that prompted this change at http://archives.postgresql.org/pgsql-jdbc/2008-01/msg00088.php
>>
>> Unfortunately the argument assumes that our users are developing new
>> applications, not using the driver in an existing application. I
>> think
>> this change should be reversed. A considerable number of people will
>> not be in a position to use an old driver with newer servers just to
>> avoid this.
>
> That's really a matter of practice - how much do you afford to
> break in order to fix previous problems or add features. Here,
> the story is to fix an unexpected behaviour of the JDBC driver
> (setQueryTimeout silently did nothing; it's *bad* to accept a
> query timeout value but then not implement any timeout; a
> correctly designed application will legally assume that the
> queries will timeout after the configured amount of time, which
> is not the case).
>
> Last year, we have upgraded from a 7.4 server to a 8.2 server. I
> can tell you that it's quite incorrect to assume that the
> application, running fine on 7.4, would magically run fine on 8.2
> too - actually, quite a lot of SQL queries were "broken", because
> of 8.2 not accepting UPDATE and DELETE FROM with implicit SELECT
> on different tables. We've had to validate our application again,
> and I think it's normal.
>
> That is to say, when the database is migrated from major
> releases, the application (or the DB layer) sometimes needs
> slight modifications, and it would be unreasonable deployment
> practices to not validate the application again anyway.


This is bound to be a controversial issue where there is no clear cut
answer. Everyone who has an app that needs it to be silent will
complain that it is now throwing an exception. Everyone who expects it
to honour the spec will complain that it doesn't work. I doubt there
are any drivers in existence which honour *all* of the spec.

That being said, my opinion is that changing it to throw an exception
will be more painful than reverting it and letting people who write
new apps code around it.

Dave

I wonder how "systematically" backward-compatibility and compliance
issues are (can be) dealt with in the driver. Just firing off a blind
shot: what about
1. drawing a base-line for non-compliant features by picking a driver
version released some suitable point in the past with which current
and future driver versions should be backward compatible and create a
list of non-compliant features of that baseline version;
2. introducing a driver option (a configuration property) for each
feature that has a compliant version to turn on the compliant
behavior;
3. having an "umbrella option" for turning on full currently possible
compliance?

Does this make sense? Or is a policy along similar lines already
implemented in the driver?

Thanks
Peter

On Tue, Mar 18, 2008 at 3:25 PM, Dave Cramer <pg@fastcrypt.com> wrote:
>
>
>  On 18-Mar-08, at 9:44 AM, Guillaume Cottenceau wrote:
>
>  > Dave Cramer <pg 'at' fastcrypt.com> writes:
>  >
>  >>> See previous discussion that prompted this change at
http://archives.postgresql.org/pgsql-jdbc/2008-01/msg00088.php
>  >>
>  >> Unfortunately the argument assumes that our users are developing new
>  >> applications, not using the driver in an existing application. I
>  >> think
>  >> this change should be reversed. A considerable number of people will
>  >> not be in a position to use an old driver with newer servers just to
>  >> avoid this.
>  >
>  > That's really a matter of practice - how much do you afford to
>  > break in order to fix previous problems or add features. Here,
>  > the story is to fix an unexpected behaviour of the JDBC driver
>  > (setQueryTimeout silently did nothing; it's *bad* to accept a
>  > query timeout value but then not implement any timeout; a
>  > correctly designed application will legally assume that the
>  > queries will timeout after the configured amount of time, which
>  > is not the case).
>  >
>  > Last year, we have upgraded from a 7.4 server to a 8.2 server. I
>  > can tell you that it's quite incorrect to assume that the
>  > application, running fine on 7.4, would magically run fine on 8.2
>  > too - actually, quite a lot of SQL queries were "broken", because
>  > of 8.2 not accepting UPDATE and DELETE FROM with implicit SELECT
>  > on different tables. We've had to validate our application again,
>  > and I think it's normal.
>  >
>  > That is to say, when the database is migrated from major
>  > releases, the application (or the DB layer) sometimes needs
>  > slight modifications, and it would be unreasonable deployment
>  > practices to not validate the application again anyway.
>
>
>  This is bound to be a controversial issue where there is no clear cut
>  answer. Everyone who has an app that needs it to be silent will
>  complain that it is now throwing an exception. Everyone who expects it
>  to honour the spec will complain that it doesn't work. I doubt there
>  are any drivers in existence which honour *all* of the spec.
>
>  That being said, my opinion is that changing it to throw an exception
>  will be more painful than reverting it and letting people who write
>  new apps code around it.
>
>  Dave
>
>
>
>  --
>  Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>  To make changes to your subscription:
>  http://www.postgresql.org/mailpref/pgsql-jdbc
>

Peter Kovacs wrote:
> I wonder how "systematically" backward-compatibility and compliance
> issues are (can be) dealt with in the driver.

We do some of this for large issues with the "compatible" connection
option. But in most cases we don't bother because it makes the driver
more complex and less maintainable.

Instead we just put API changes in the current development version only
and don't backport to older stable drivers, under the assumption that
people will not blindly move their applications to a new major version
without retesting.

-O