JDBC and threads

[Jonck van der Kogel]

Hi,
I have a question on threads, probably very basic but I'm having a
hard time figuring it out. I've created a little test app for
experimentation on this subject.
The app shows a JTable that is filled with data from a database. The
user can change the data in the JTable wherupon the JTable passes this
data to the database. Now this part I would like to do in a different
thread, so that the UI is not slowed when communication with the
database is taking place. To do this I've created a class has a
private class that extends Thread. The run() method of this class is
then supposed to do the JDBC stuff like creating a statement and
executing the update.
However, here I have a problem. The run() method cannot throw an
SQLException. I would like the exception to be thrown rather than
caught in the run() method, so that I can deal with the exception in
my main thread and have the UI respond accordingly (meaning: do not
update the tableModel with the newly entered value).

Does anyone have any suggestions for me how I could implement this in
a different fashion? The aim is to get the JDBC stuff to run in a
different thread than the UI does.

Thanks very much, Jonck

 

[Matt Humphrey]

Hi,
I have a question on threads, probably very basic but I'm having a
hard time figuring it out. I've created a little test app for
experimentation on this subject.
The app shows a JTable that is filled with data from a database. The
user can change the data in the JTable wherupon the JTable passes this
data to the database. Now this part I would like to do in a different
thread, so that the UI is not slowed when communication with the
database is taking place. To do this I've created a class has a
private class that extends Thread. The run() method of this class is
then supposed to do the JDBC stuff like creating a statement and
executing the update.
However, here I have a problem. The run() method cannot throw an
SQLException. I would like the exception to be thrown rather than
caught in the run() method, so that I can deal with the exception in
my main thread and have the UI respond accordingly (meaning: do not
update the tableModel with the newly entered value).

Working with threads requires thinking about things a little differently.
If the Thread.run method did throw any kind of exception who would catch it?
The UI thread that started the thread is off doing something else and cannot
deal with it. If you don't catch that exception your thread will simply die
on the spot and you won't have any chance to take useful action.

You have to catch the exceptions (all of them, really) within your run
method and send the information into the UI thread. Except for a handful of
cases, this is ultimately done with the "invokeLater" method (or a
variation) which allows you to perform a Runnable (void run()) in the UI
thread. The UI thread executes the runnable when it gets around to it. This
runnable would then update the JTable, popup dialog boxes, change UI state,
whatever you like.

There are lots of ways to design this depending on what you're trying to
achieve. Having worked on many collaborative / distributed systems I prefer
to let the thread task object communicate with my main app via an interface
so that it knows nothing about the UI. There are quite a number of important
design issues here, including updating the UI, multiple tasks, task thread
synchonrization, etc, so it may take you some time to work out what you
need.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/