Ok fair enough you can periodically check at interval on synchronised boolean to
cancel an operation. But I am disappointed.
The reason why I asked is because I use the JDBC. The current JDBC API does not
allow the operator to have a callback or to read selective rows from the
database. In other words:
Class.forName( "org.blackdown.jdbc.AnyOldDriver" );
Connection con = DriverManager.getConnection( url, username, password );
Statement stmt = con.createStatement( "select * from JDK_RELEASES" );
stmt.executeQuery(); // One atomic call with no way to run to !!!
Here is a case where it is NOT EASY to apply your notification if your table had
100000 rows.
I have a spawn threads to execute the above SQL query and then allowed to
operator to kill the thread if the query was slow. Hope fully the GC will
clean up afterwards. [In fact the forthcoming Xenon-SQL depends on it]
I guess the way to go will be:
1) Not to write API atomic slow methods like `executeQuery'
Instead use an Iterator or Cursor whatever man
2) Hopefully JDBC 2.0 will provide a method to retrieve N rows at a time.
A cursor.
Pete
______________________________ Reply Separator _________________________________
Subject: Re: Deprecated `Thread.stop()' in forthcoming JDK 1.2. Wh
Author: Michael.Sinz ([EMAIL PROTECTED]) at lon-mime
Date: 13/11/98 15:32
On Fri, 13 Nov 1998 15:15:29 +0000, [EMAIL PROTECTED] wrote:
> I read somewhere that Thread.stop() is now deprecated. Now how on
> earth do we stop a thread ?
> I thought the solution would be Thread.interrupt()
> but that only works when the thread is sleeping, at least in JDK 1.1
> documentation.
>
> I do not have the JDK 1.2 to hand, and I have started use multiple
> threads in Swing/JFC/. It seems to be idiocy to have a start method
> and not have a stop method. The stop() method justs halts the thread
> object and the garbage collector collects any rubbish.
>
> Thoughts?
There are reasons for some of the thread changes, mainly that the JVM
can not control the threads as well on native threading systems (even
more so when the thread is maybe running on another CPU) There would
be far too much overhead in normal operation.
You can implement your own thread operations but you would then need to
have the overhead only in those cases. (It also will have the same
problems with multi-processor/native thread operations and the like
but if you really want a harsh stop(), it may be the only way)
I too like the feature but it is easy enough to have your own notification.
A harsh stop may not be able to control what is happening at the moment or
it would have to only check at certain points within the operations.
Michael Sinz -- Director of Research & Development, NextBus Inc.
mailto:[EMAIL PROTECTED] --------- http://www.nextbus.com
My place on the web ---> http://www.users.fast.net/~michael_sinz
