Re: [Gusdev-gusdev] Boolean query error

[Arnaud K. <ax...@sa...>]

Hi

I think we found a way to fix this problem.

We've added
this line
    => stmt.setQueryTimeout (this.maxQueryTimeout);
in the getStatement() method in ConnectionPool class.

As a consequence the inner class Reaper in ConnectionPool is not in use
any longer.

cheers
Arnaud

public Statement getStatement() {

    / / ...

    stmt.setQueryTimeout (this.maxQueryTimeout);

    // ...

} catch (SQLException sqle) {
    // ...
}

Steve Fischer wrote:

> ok.  then just to clarify a dead horse, the Boolean query error is a
> secondary effect.  the primary problem, as i think you guys have been
> exploring, is that we are not handling timed out queries correctly.
> in particular, as arnaud speculates, we are getting an entry in
> Queries which points to a non-existent cache table.
>
> steve
>
> Arnaud Kerhornou wrote:
>
>> That's all correct.
>>
>> I haven't investigated further but I reckon the reference to the
>> non-existent
>> cache table in an entry in the queries table (correct me if I'm
>> wrong). So we
>> need a way to delete this entry or roll it back if it is possible.
>>
>> Quoting Steve Fischer <st...@pc...>:
>>
>>
>> > if i understand paul correctly, then the problem is this:
>> >   1. query 1 produces SQLIdResultTable_1
>> >   2. query 2 times out, leaving as an artifact a broken
>> > SQLIdResultTable, ie one without a valid cached result.
>> >   3. the boolean intersect operator tries to intersect these and
>> > bombs
>> > out, producing an empty result?
>> >   4. is it also the case that if the user tries to redo query 2,
>> > outside
>> > of the boolean context, then it again produces no result because it
>> > is
>> > trying to reference the non-existent cache table?
>> >
>> > steve
>> >
>> >
>> > Pjm wrote:
>> >
>> >
>> >>  Adrian Roy Tivey wrote:
>> >>
>> >>
>> >> >>  Arnaud-
>> >> >>
>> >> >>  Jonathan has handed responsibility for the WDK over to me and
>> >> >>  Angel,
>> >> >>  since he has moved to D.C.
>> >> >>
>> >> >>  I'll look into it.  Feel free to delve into the code and find
>> >> >>  out
>> >> >>  whatever you can.
>> >> >>
>> >> >>  Steve
>> >> >>
>> >> > Does anybody know how reliable Statement.setQueryTimeout is on
>> >> > Oracle? If it's
>> >> > robust we could easily switch to that. Then we get the timeout
>> >> > report
>> >> > in (more
>> >> > or less) the right bit of the code to handle it.
>> >> >
>> >>  The statement timeout code works fine. Its more the fact that if
>> >>  one
>> >>  of the sub queries fails (for whatever reason) then the
>> >>  cacheXXXX
>> >>  table does not get created. Thus the query that intersects with
>> >>  it
>> >>  will also fail. The code does not handle this and the results
>> >>  page has
>> >>  a table with no rows.
>> >>
>> >>  The next time that query runs it will look for the cacheXXXX
>> >>  table and
>> >>  fail. The user will think the query found nothing.
>> >>
>> >>  Paul.
>> >>
>> >>