db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1848) jdbcapi/SetQueryTimeoutTest.java fails on IBM wctme 5.7
Date Tue, 03 Jun 2008 20:42:45 GMT

    [ https://issues.apache.org/jira/browse/DERBY-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602064#action_12602064

Mamta A. Satoor commented on DERBY-1848:

Around each position moving request on a ResultSet object (next/previous/first/last etc),
Derby pushes the StatementContext for that Statement (EmbedResultSet.movePosition). And once
the ResultSet positioning is over, the StatementContext is popped back. This happens in EmbedResultSet.moveposition(int,int,String)

During the pushing of the StatementContext (in GenericLangaugeConnectionContext.pushStatementContext),
we mark the StatementContext to 
be in use by calling  GenericStatementContext.setInUse. This setInUse method checks if query
timeout is set on the Statement, and if yes, then it starts a Timer which uses CancelQueryTask
to keep track of when the Statement execution should be marked timedout (The setting of the
CancelQueryTask happens in GenericStatementContext.setInUse).

Once the requested positioning is done on the ResultSet object, Derby goes through the process
of popping the StatementContext. This happens in GenericLangaugeConnectionContext.popStatementContext.
Here, we mark the StatementContext as not in use since we are going to pop the StatementContext.
This work gets done in GenericStatementContext.clearInUse. clearInUse checks if there is a
timeout timer associated with the StatementContext (this association was done in pushStatementContext)
and if yes, then it disassociates the timer and then marks the timer object as null. It also
goes ahead and marks the cancel query flag to flase (cancellationFlag). The cancellationFlag
tells whether the query associated with the StatementContext has exceeded the timeout limit.
If user never set a query timeout on the Statement object, cancellationFlag will always be
false. But if the user has set a query timeout, then this flag will be set to true by the
CancelQueryTask when it finds that the Statement has run over it's limit of timeout amount.
We do not throw an exception for query timeout as soon as the flag gets set to true. The cancellationFlag
gets checked only when the user has requested a position movement on the ResultSet object.

So, one possible scenario can be that we push a StatementContext because user has requested
say, ResultSet.next. During push, we set a query timeout timer because user has requested
for timeout on the query. Then we go through the code for moving to next row in the ResultSet.
The first thing we check there is if the query is marked cancelled (by checking cancellationFlag
on StatementContext). If yes, then we throw an exception. But for this case, let's assume
the query has not timeed out yet. Hence we go through the rest of the code for moving to next
row. While we are doing
this(ie before we are finished with the code for moving to next row), say the timer times
out and the timer goes and sets cancellationFlag to true (this happens in CancelQueryTask.run()
which lives in the class GenericStatementContext). But this setting of flag is little too
late for the current movement within the ResultSet object because we had just checked the
flag earlier and it was set to false at that time. So, at this point, we just finish the ResultSet
movement and then pop the StatementContext without throwning any exception. If the user has
asked for another ResultSet movement after the current one, we will catch the query timeout,
go through popping the current Statement Context and then throw an exception. The 
popping of the StatementContext marks the StatementContext associated with the query timeout
timer to false and then it nullifies the query timeout timer.

What seems to be happening in case of weme6.1 occassionally is that once the query timeout
has been set and detected (which causes us to nullify the CancelQueryTask associated with
the StatementContext being popped and throw exception), Derby somehow manages to set the query
timeout to true again and we end up detecting it again and apparently we associate that timeout
with a StatementContext that has not even requested a query timeout on it.

I wondered if someone familiar with this query timeout code can see what can cause us to set
the timeout again when apparently we have nulled out the timer (in GenericLangaugeConnectionContext.popStatementContext).

> jdbcapi/SetQueryTimeoutTest.java fails on IBM  wctme 5.7
> --------------------------------------------------------
>                 Key: DERBY-1848
>                 URL: https://issues.apache.org/jira/browse/DERBY-1848
>             Project: Derby
>          Issue Type: Test
>          Components: Regression Test Failure
>    Affects Versions:,,
>         Environment: Windows
>            Reporter: Rajesh Kartha
>            Assignee: Mamta A. Satoor
>         Attachments: DERBY_1848_Repro.java, DERBY_1848_Repro.java
> The following is the diff:
> *** Start: SetQueryTimeoutTest jdk1.3.1 subset - 2.2 derbyall:jdbcapi 2006-09-10 11:07:05
> 7 del
> < Statement 1 completed
> 8 del
> < Statement 2 completed
> 9 del
> < Statement 3 completed
> 10 del
> < Testing timeout with an execute operation
> 11 del
> < Statements that should time out timed out, and statements that should complete completed
> 12 del
> < Testing setting a negative timeout value
> 13 del
> < Negative timeout value caused exception, as expected
> 14 del
> < Execute returned a ResultSet
> 15 del
> < Testing that Statement remembers timeout.
> 16 del
> < Testing that PreparedStatement remembers timeout.
> 17 del
> < Testing that CallableStatement remembers timeout.
> 18 del
> < Testing timeout with executeUpdate call.
> 19 del
> < Test SetQueryTimeoutTest PASSED
> 19a7,11
> > Test SetQueryTimeoutTest FAILED
> > org.apache.derbyTesting.functionTests.tests.jdbcapi.SetQueryTimeoutTest$TestFailedException:
Unexpected exception in 1: java.sql.SQLException: The statement has been cancelled or timed
> > ERROR XCL52: The statement has been cancelled or timed out.
> > java.sql.SQLException: Invalid transaction state.
> > java.sql.SQLException: Invalid transaction state.
> Test Failed.
> *** End:   SetQueryTimeoutTest jdk1.3.1 subset - 2.2 derbyall:jdbcapi 2006-09-10 11:07:26

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message