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
now.
Craig
Regards
--
Andy
DataNucleus (http://www.datanucleus.org)
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@oracle.com
P.S. A good JDO? O, Gasp!
