Re: setQueryTimeOut(1) - not expected result...

Guido Fiala wrote:
> Am Mittwoch, 28. Januar 2004 22:21 schrieben Sie:
>
>>Guido Fiala wrote:
>>
>>>//user1:
>>>
>>>stmt.setQueryTimeout(1);//wait just one second
>>>ResultSet rs=stmt.executeQuery("BEGIN;SELECT * FROM mytable FOR UPDATE OF
>>>mytable");
>>
>>>What am i doing wrong?
>>
>>You are assuming that setQueryTimeout() is implemented :) Calling it
>>does nothing in the current driver. This is on my list of things to fix,
>
>
> As i really need this - maybe i could implement that feature myself and
> contribute it here? I assume, it's not much more to set some IO-timeout on
> the socket-read() after sending the query...

It's harder than that, unfortunately. If you just time-out the read, you
either have to drop the connection entirely or wait for the backend to
complete the original query before you can do further queries (the
backend doesn't know you've given up on that query so will still be
running it).

A better approach is probably to use the query cancellation protocol to
cancel the outstanding query at the backend once the query times out.
This should cause the backend to give up on the query and return an
error, and you should get a fairly prompt SQLException.

>>but not near the top.
>
>
> Mmmm, is there any possibility to stop that query using another thread in the
> same application?

Yes -- see Statement.cancel(), which uses the query cancellation
protocol I mentioned above. You can implement something like
setQueryTimeout() using that and a timer thread. It's going to be a bit
ugly though since the JDBC API makes it very hard (impossible?) to avoid
race conditions between starting the query and cancelling it.

>>On another note, it's generally a bad idea to use the transaction
>>control primitives (BEGIN, COMMIT, ROLLBACK) directly -- use
>>Connection.setAutoCommit(false) and Connection.commit() /
>>Connection.rollback() instead.
>
>
> Yes, but wouldn't i then need a lot of connections, one for each data display
> in my application?

I'm not sure why this would change how many connections you need.. you
can still only have one transaction per connection regardless of whether
you use explicit BEGIN/COMMIT or the JDBC interface methods. The
implementation of Connection.setAutoCommit() and friends just arranges
to have BEGIN etc. sent at the right places. It's safer to let the
driver handle this as there are cases where it needs to know what state
the connection is in (transaction vs. no transaction) and doing your own
transaction demarcation is likely to confuse it. It's a lot more
portable too..

-O