SwingWorker: don't stop that train!

So imagine you're comfortably sleeping at home. Suddenly you wake up and you find out you're sitting in your car, driving at 65 MPH in the highway. That's a dangerous situation, right?

Now imagine you're a JDBC driver and you're comfortably performing a query against a server. You're talking, say, OCI to an Oracle server. Suddenly someone "Thread.interrupt()"s you and then asks you to "close()" the JDBC connection. You may be able to successfully close the connection. Or you may not. Maybe you can close the connection, but the server is left in a weird state, thinking you're still asking for the query.

What I mean is that Thread.interrupt() (or SwingWorker.cancel()) certain operations may not be a very good idea. By interrupting threads you may be interrupting network protocols, for instance, and that may be asking for trouble with some JDBC drivers. You can build a SQL application and interrupt and close the connections perfectly well with a given driver, and completely fail with another driver.

What I really mean is that if you want to suddenly cancel a running process (whatever that is) you should try to do that in the safest, cleanest way. An idea is to use a "boolean wantsToRun=true" flag somewhere in your SwingWorker constructors and keep the things rolling in the "doInBackground()" method as long as "wantsToRun" is true.

So there comes our SwingWorker suggestion number II:

SwingWorker suggestion II: try to cancel() as cleanly as possible Use a flag in your "doInBackground()" loops to check if your SwingWorker is still expected to be run. Since you cannot override "cancel(boolean)" in your SwingWorker (it's final :-( ) then write a method to gracefully ask for cancellation. If you use SwingWorker.cancel(true) to stop your running process doublecheck that everything is correctly cancelled by thoroughly testing your application.
Note that this suggestion applies to SwingWorkers and to any Thread you build.

So, to summarize, think it twice before suddenly stopping trains Threads. Results might be quite different from what you expect.

Happy Swinging,
Antonio

Comentarios:

OK, nothing new under the sun here... and anyway, I would probably not have tried Connection.close(), but what do you actually do when you know the query you have launched will take ages and you absolutely want to stop it?

Enviado por Davis en agosto 17, 2005 a las 12:46 AM CEST #

If you absolutely want to stop it you'll interrupt it, of course. And afterwards you'll invoke close() on the connection.

What I mean is that it may fail. Depends on the JDBC driver you're using and on when you invoke interrupt(). You need to test it: it's a way to stop an ongoing JDBC call, but it's not a clean way to do it.

Enviado por Antonio en agosto 17, 2005 a las 12:53 PM CEST #

So what about when we're waiting for the results from an RMI call and not a JDBC Connection?

Enviado por Neil Weber en agosto 19, 2005 a las 04:16 PM CEST #

Hi Antonio, A suggestion for a future entry... I have an app where resizing the window results in quite a bit of recomputation before the display can be updated. When full-window dragging is enabled, a few repaint events can happen every second. I think SwingWorkers are probably the way to go, where the previous one gets cancelled before launching a new one. Any insights would be appreciated.

Enviado por Chris Nokleberg en septiembre 05, 2005 a las 06:06 AM CEST #

Enviar un comentario:
Los comentarios han sido deshabilitados.
About

swinger

Search

Archives
« abril 2014
lunmarmiéjueviesábdom
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Hoy