JDBC and threads

java-programmer, JDBC and threads 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

java-programmer >> JDBC and threads Hi again,
I just realized why the run() method is never going to be able to
throw anything: because the code that launched the thread will
possibly be beyond the catch block by the time an exception is thrown.
So I guess this means that I will have to encapsulate the entire
transaction with the database as well as updating the tableModel (or
not if an SQLException is thrown) in the run() method?

Thanks, Jonck

java-programmer >> JDBC and threads
"Jonck van der Kogel" <email***@***.com> wrote in message
news:email***@***.com...
> 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 email***@***.com http://www.iviz.com/