You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Andy Jefferson <an...@datanucleus.org> on 2010/03/11 12:53:16 UTC
TCK tests : QueryCancel
Hi,
Finally got around to running these tests with an implementation of JDOQL that
supports cancellation. I logged the point of calls to Query.cancel,
Query.execute etc.
11:48:59,211 (main) INFO [DataNucleus.General] - >> testCancel : creating
query
11:48:59,240 (main) DEBUG [DataNucleus.Query] - JDOQL Single-String with
"select avg (this.x + point2.y) from PCPoint where this.y >= 0 && point2.x >=
0 variables PCPoint2 point2 import org.apache.jdo.tck.pc.mylib.PCPoint; import
org.apache.jdo.tck.pc.mylib.PCPoint2; "
11:48:59,248 (main) INFO [DataNucleus.General] - >> testCancel : calling
query.cancel() from main thread
11:48:59,248 (Query Executor) DEBUG [DataNucleus.Transaction] - Transaction
created [DataNucleus Transaction, ID=Xid=
, enlisted resources=[]]
11:48:59,248 (main) INFO [DataNucleus.General] - >> Query.cancelThread
thread=21 numTasks=0
11:48:59,249 (Query Executor) DEBUG [DataNucleus.Transaction] - Transaction
begun for ObjectManager org.datanucleus.ObjectManagerImpl@9b6220
(optimistic=false)
11:48:59,249 (Query Executor) INFO [DataNucleus.General] - >> testCancel :
Calling query.execute from thread
11:48:59,249 (Query Executor) DEBUG [DataNucleus.Query] - JDOQL Query :
Compiling "SELECT avg (this.x + point2.y) FROM
org.apache.jdo.tck.pc.mylib.PCPoint WHERE this.y >= 0 && point2.x >= 0
VARIABLES PCPoint2 point2 import org.apache.jdo.tck.pc.mylib.PCPoint;import
org.apache.jdo.tck.pc.mylib.PCPoint2;"
so the conclusion is that the test cancels (or tries to cancel) the query that
it hasn't yet started!
What is the expected behaviour of Query.cancel(Thread) when there are no
queries running in that thread ? noop makes sense to me. That's what
DataNucleus does; the test doesn't cater for that situation.
Suggest that the test needs to allow the query to get to execute() before it
cancels it
Regards
--
Andy
DataNucleus (http://www.datanucleus.org)
Re: TCK tests : QueryCancel
Posted by Andy Jefferson <an...@datanucleus.org>.
Same logic applies to the DatastoreTimeout test(s). The timeout only applies
to the datastore operation, yet will be imposed against the overall call to
the JDO API (query execution). Consequently the results are currently
unreliable.
DataNucleus 2.0 passes since the JDOQL implementation in use in that version
doesn't support timeouts or cancelling. The one that will be in DataNucleus
2.1 will support them.
--
Andy
DataNucleus (http://www.datanucleus.org)
Re: TCK tests : QueryCancel
Posted by Erik Bengtson <er...@jpox.org>.
If you provide a query parameter and lock the parameter object in your
thread, you might be able to have the other thread waiting you to
unlock, so you can execute the cancel.
On Sun, Mar 14, 2010 at 7:50 PM, Michael Bouschen <mb...@spree.de> wrote:
> Hi Andy, hi Craig,
>
> I'm surprised about the query execution time of 60 ms to 2 ms. Andy, your
> hardware seems to be much faster than mine :-).
>
> I agree we should change the test such that the query takes longer to
> execute. I propose to create more test instances, then the join (as part of
> the query) becomes more expensive.
>
> Attached you find a patch with the following changes of the test class:
> - it creates 5000 PCPoint and PCPoint2 instances (instead of 1000)
> - uses a barrier to synchronize the threads
> - compiles the query before staring the thread
>
> Regards Michael
>
>> 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.Russell@oracle.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>
>
> --
> *Michael Bouschen*
> *Prokurist*
>
> akquinet tech@spree GmbH
> Bülowstr. 66, D-10783 Berlin
>
> Fon: +49 30 235 520-33
> Fax: +49 30 217 520-12
> Email: michael.bouschen@akquinet.de
> Url: www.akquinet.de <http://www.akquinet.de>
>
> akquinet tech@spree GmbH, Berlin
> Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
> Amtsgericht Berlin-Charlottenburg HRB 86780 B
> USt.-Id. Nr.: DE 225 964 680
>
> Index: src/java/org/apache/jdo/tck/query/api/QueryCancel.java
> ===================================================================
> --- src/java/org/apache/jdo/tck/query/api/QueryCancel.java (Revision
> 922445)
> +++ src/java/org/apache/jdo/tck/query/api/QueryCancel.java
> (Arbeitskopie)
> @@ -17,6 +17,8 @@
>
> package org.apache.jdo.tck.query.api;
>
> +import java.util.concurrent.CyclicBarrier;
> +
> import junit.framework.AssertionFailedError;
>
> import javax.jdo.JDOFatalException;
> @@ -50,8 +52,11 @@
> public class QueryCancel extends QueryTest {
>
> /** Time for the main thread to sleep after starting a parallel thread.
> */
> - private static int MAIN_SLEEP_MILLIS = 1000;
> + private static int MAIN_SLEEP_MILLIS = 20;
>
> + /** Number of instances to be created. */
> + private static int NO_OF_INSTANCES = 5000;
> +
> /** */
> private static final String ASSERTION_FAILED =
> "Assertion A14.6.1-8 (QueryCancel) failed: ";
> @@ -77,18 +82,24 @@
> /** */
> public void testCancel() throws Exception {
> PersistenceManager pm = getPM();
> + // Test query
> Query query = pm.newQuery(SSJDOQL);
> + query.compile();
>
> // Thread executing the query
> + CyclicBarrier barrier = new CyclicBarrier(2);
> ThreadExceptionHandler group = new ThreadExceptionHandler();
> - QueryExecutor runnable = new QueryExecutor(pm, query);
> + QueryExecutor runnable = new QueryExecutor(pm, query, barrier);
> Thread t = new Thread(group, runnable, "Query Executor");
> t.start();
>
> - // Wait for a second such that the other thread can execute the
> query
> - Thread.sleep(MAIN_SLEEP_MILLIS);
> + try {
> + // Wait for the other thread
> + barrier.await();
>
> - try {
> + // Wait a couple of millis such that the other thread can start
> query execution
> + Thread.sleep(MAIN_SLEEP_MILLIS);
> +
> // cancel query
> query.cancel(t);
> if (!isQueryCancelSupported()) {
> @@ -119,19 +130,25 @@
> /** */
> public void testCancelAll() throws Exception {
> PersistenceManager pm = getPM();
> + // Test query
> Query query = pm.newQuery(SSJDOQL);
> + query.compile();
>
> // Thread executing the query
> + CyclicBarrier barrier = new CyclicBarrier(2);
> ThreadExceptionHandler group = new ThreadExceptionHandler();
> - QueryExecutor runnable = new QueryExecutor(pm, query);
> + QueryExecutor runnable = new QueryExecutor(pm, query, barrier);
> Thread t = new Thread(group, runnable, "Query Executor");
> t.start();
>
> - // Wait for a second such that the other thread can execute the
> query
> - Thread.sleep(MAIN_SLEEP_MILLIS);
> -
> try {
> // cancel query
> + // Wait for the other thread
> + barrier.await();
> +
> + // Wait a couple of millis such that the other thread can start
> query execution
> + Thread.sleep(MAIN_SLEEP_MILLIS);
> +
> query.cancelAll();
> if (!isQueryCancelSupported()) {
> fail(ASSERTION_FAILED,
> @@ -162,17 +179,23 @@
> class QueryExecutor implements Runnable {
>
> PersistenceManager pm;
> + CyclicBarrier barrier;
> Query query;
>
> - QueryExecutor(PersistenceManager pm, Query query) {
> + QueryExecutor(PersistenceManager pm, Query query, CyclicBarrier
> barrier) {
> this.pm = pm;
> this.query = query;
> + this.barrier = barrier;
> }
>
> public void run() {
> Transaction tx = pm.currentTransaction();
> try {
> tx.begin();
> +
> + // wait for the other thread
> + barrier.await();
> +
> Object result = query.execute();
> tx.commit();
> tx = null;
> @@ -189,6 +212,9 @@
> "if query canceling is not supported.");
> }
> }
> + catch (Exception ex) {
> + throw new RuntimeException(ex);
> + }
> finally {
> if ((tx != null) && tx.isActive())
> tx.rollback();
> @@ -208,11 +234,11 @@
> Transaction tx = pm.currentTransaction();
> try {
> tx.begin();
> - for (int i = 0; i < 1000; i++) {
> + for (int i = 0; i < NO_OF_INSTANCES; i++) {
> PCPoint obj = new PCPoint(i, i);
> pm.makePersistent(obj);
> }
> - for (int i = 0; i < 1000; i++) {
> + for (int i = 0; i < NO_OF_INSTANCES; i++) {
> PCPoint2 obj = new PCPoint2(i, i);
> pm.makePersistent(obj);
> }
>
>
Re: TCK tests : QueryCancel
Posted by Michael Bouschen <mb...@spree.de>.
Hi Andy, hi Craig,
I'm surprised about the query execution time of 60 ms to 2 ms. Andy,
your hardware seems to be much faster than mine :-).
I agree we should change the test such that the query takes longer to
execute. I propose to create more test instances, then the join (as part
of the query) becomes more expensive.
Attached you find a patch with the following changes of the test class:
- it creates 5000 PCPoint and PCPoint2 instances (instead of 1000)
- uses a barrier to synchronize the threads
- compiles the query before staring the thread
Regards Michael
> 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.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
--
*Michael Bouschen*
*Prokurist*
akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin
Fon: +49 30 235 520-33
Fax: +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Url: www.akquinet.de <http://www.akquinet.de>
akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680
Re: TCK tests : QueryCancel
Posted by Craig L Russell <Cr...@SUN.com>.
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.Russell@oracle.com
P.S. A good JDO? O, Gasp!
Re: TCK tests : QueryCancel
Posted by Andy Jefferson <an...@datanucleus.org>.
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.
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.
Shouldn't the test also take into account if the query does actually return
the results before the cancel can be called ?
Regards
--
Andy
DataNucleus (http://www.datanucleus.org)
Re: TCK tests : QueryCancel
Posted by Michael Bouschen <mb...@spree.de>.
Hi Andy,
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?
I agree that Query.cancel should be a noop, if query execution hasn't
been started or is already terminated.
Regards Michael
> Hi,
>
> Finally got around to running these tests with an implementation of JDOQL that
> supports cancellation. I logged the point of calls to Query.cancel,
> Query.execute etc.
>
> 11:48:59,211 (main) INFO [DataNucleus.General] - >> testCancel : creating
> query
> 11:48:59,240 (main) DEBUG [DataNucleus.Query] - JDOQL Single-String with
> "select avg (this.x + point2.y) from PCPoint where this.y >= 0 && point2.x >=
> 0 variables PCPoint2 point2 import org.apache.jdo.tck.pc.mylib.PCPoint; import
> org.apache.jdo.tck.pc.mylib.PCPoint2; "
> 11:48:59,248 (main) INFO [DataNucleus.General] - >> testCancel : calling
> query.cancel() from main thread
> 11:48:59,248 (Query Executor) DEBUG [DataNucleus.Transaction] - Transaction
> created [DataNucleus Transaction, ID=Xid=
> , enlisted resources=[]]
> 11:48:59,248 (main) INFO [DataNucleus.General] - >> Query.cancelThread
> thread=21 numTasks=0
> 11:48:59,249 (Query Executor) DEBUG [DataNucleus.Transaction] - Transaction
> begun for ObjectManager org.datanucleus.ObjectManagerImpl@9b6220
> (optimistic=false)
> 11:48:59,249 (Query Executor) INFO [DataNucleus.General] - >> testCancel :
> Calling query.execute from thread
> 11:48:59,249 (Query Executor) DEBUG [DataNucleus.Query] - JDOQL Query :
> Compiling "SELECT avg (this.x + point2.y) FROM
> org.apache.jdo.tck.pc.mylib.PCPoint WHERE this.y >= 0 && point2.x >= 0
> VARIABLES PCPoint2 point2 import org.apache.jdo.tck.pc.mylib.PCPoint;import
> org.apache.jdo.tck.pc.mylib.PCPoint2;"
>
> so the conclusion is that the test cancels (or tries to cancel) the query that
> it hasn't yet started!
>
> What is the expected behaviour of Query.cancel(Thread) when there are no
> queries running in that thread ? noop makes sense to me. That's what
> DataNucleus does; the test doesn't cater for that situation.
> Suggest that the test needs to allow the query to get to execute() before it
> cancels it
>
>
>
> Regards
>
--
*Michael Bouschen*
*Prokurist*
akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin
Fon: +49 30 235 520-33
Fax: +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Url: www.akquinet.de <http://www.akquinet.de>
akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680
Re: TCK tests : QueryCancel
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Andy,
Sounds like some more sophisticated thread synchronization is needed
in the test cases.
Craig
On Mar 11, 2010, at 3:53 AM, Andy Jefferson wrote:
> Hi,
>
> Finally got around to running these tests with an implementation of
> JDOQL that
> supports cancellation. I logged the point of calls to Query.cancel,
> Query.execute etc.
>
> 11:48:59,211 (main) INFO [DataNucleus.General] - >> testCancel :
> creating
> query
> 11:48:59,240 (main) DEBUG [DataNucleus.Query] - JDOQL Single-String
> with
> "select avg (this.x + point2.y) from PCPoint where this.y >= 0 &&
> point2.x >=
> 0 variables PCPoint2 point2 import
> org.apache.jdo.tck.pc.mylib.PCPoint; import
> org.apache.jdo.tck.pc.mylib.PCPoint2; "
> 11:48:59,248 (main) INFO [DataNucleus.General] - >> testCancel :
> calling
> query.cancel() from main thread
> 11:48:59,248 (Query Executor) DEBUG [DataNucleus.Transaction] -
> Transaction
> created [DataNucleus Transaction, ID=Xid=
> , enlisted resources=[]]
> 11:48:59,248 (main) INFO [DataNucleus.General] - >>
> Query.cancelThread
> thread=21 numTasks=0
> 11:48:59,249 (Query Executor) DEBUG [DataNucleus.Transaction] -
> Transaction
> begun for ObjectManager org.datanucleus.ObjectManagerImpl@9b6220
> (optimistic=false)
> 11:48:59,249 (Query Executor) INFO [DataNucleus.General] - >>
> testCancel :
> Calling query.execute from thread
> 11:48:59,249 (Query Executor) DEBUG [DataNucleus.Query] - JDOQL
> Query :
> Compiling "SELECT avg (this.x + point2.y) FROM
> org.apache.jdo.tck.pc.mylib.PCPoint WHERE this.y >= 0 && point2.x >= 0
> VARIABLES PCPoint2 point2 import
> org.apache.jdo.tck.pc.mylib.PCPoint;import
> org.apache.jdo.tck.pc.mylib.PCPoint2;"
>
> so the conclusion is that the test cancels (or tries to cancel) the
> query that
> it hasn't yet started!
>
> What is the expected behaviour of Query.cancel(Thread) when there
> are no
> queries running in that thread ? noop makes sense to me. That's what
> DataNucleus does; the test doesn't cater for that situation.
> Suggest that the test needs to allow the query to get to execute()
> before it
> cancels it
>
>
>
> Regards
> --
> Andy
> DataNucleus (http://www.datanucleus.org)
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!