db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@SUN.com>
Subject Re: TCK tests : QueryCancel
Date Sat, 13 Mar 2010 18:14:29 GMT
Hi Andy,

On Mar 13, 2010, at 3:29 AM, Andy Jefferson wrote:

> Hi Michael,
>> I added a Thread.sleep(1000) to the main thread in order to give the
>> other thread a chance to start the query before the main thread  
>> cancels
>> it. Could you please give it a try?
> Giving something a second to get started seems excessive, I know  
> Derby is slow
> but ... ;-)
> I tried with a value more like 80 or 100 (millis) and managed **on  
> occasions**
> to get a JDOQueryInterruptedException (and pass the test). Other  
> times the
> cancel still got in first. I also added a query.compile() before  
> starting the
> threads hence less for the query execute to do before starting, but  
> still
> intermittent. The intermittency will also be affected by the machine  
> being
> used, hence the number is arbitrary. The query execution time (in the
> datastore) is anywhere between 60ms and 2ms on my machine.

This test will always be somewhat sensitive to timing, but we should  
be able to minimize the timing effects.

The query itself should be long enough to allow the cancel to have an  
effect. The query execution time of 60 ms to 2 ms. [sic] doesn't sound  
long enough. Maybe we need to make the query more complex. But still,  
as machines get faster the query execution times will get smaller.

The other thing we discussed earlier was the possibility of needing a  
barrier so we could guarantee that the two threads were synchronized  
at some point. The main thread calling start doesn't quite guarantee  
synchronization, while a barrier of size two should do it. Still,  
assuming that the query is compiled before the barrier, and the main  
thread yields to the query thread (sleep should do this just fine) we  
should be able to get the query to start and the cancel to interrupt it.
> Depends what the cancel is allowing cancel over; to be consistent  
> with the
> timeout I assume it is cancel the datastore operation (as opposed to  
> the whole
> query execute process ... compile, generate PreparedStatement,  
> populate
> parameter values, execute in the datastore, return results), and so
> DataNucleus only starts the execution in a separate thread and  
> maintains the
> handle on that thread for cancellation purposes. If this execution  
> thread is
> either not yet created, or is now finished then the test will fail,  
> always.

Another good high level discussion. Since we have the datastore read  
timeout, the purpose of the cancel is to stop query execution before  
the timeout expires. Since we assume that the main thread and the  
query thread have ways of communicating as long as the query thread is  
not stuck in a datastore wait, we are only concerned about getting the  
query thread unstuck.

So if the query has already returned results, the purpose for cancel  
doesn't exist. There still may be a timing issue in real life where  
the main thread sees that the query thread is stuck, but by the time  
it gets around to canceling the query, the query thread is no longer  
stuck. So it doesn't really matter whether the cancel worked or not.  
That's why I agree that a reasonable behavior is having the cancel be  
a no-op in case it can't find anything to do.

But we still want a test case. Do we need the test case to perform  
some timing tests to see how long queries take and adjust the wait  
time accordingly? Do we want to try different values and require that  
at least one value succeed? Start with a value of 1 ms and raise by  
increments until the cancel works?
> Shouldn't the test also take into account if the query does actually  
> return
> the results before the cancel can be called ?

This could be part of the heuristics as noted above. Much better if we  
can figure out a good barrier/sleep strategy that at least works for  

> Regards
> -- 
> Andy
> DataNucleus (http://www.datanucleus.org)

Craig L Russell
Architect, Oracle
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!

View raw message