File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Worker Threads Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Worker Threads" Watch "Worker Threads" New topic
Author

Worker Threads

Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
I have a question about worker threads that I am a bit perplexed on. I'm using sockets for my network implementation. Here's my question: have a hashmap in my data's lock method that first checks to make sure the current thread does not already 1) hold a lock on the called record or 2)already hold a lock on some record. However, if I use worker threads, I don't think it'll work. In my MainUIWindow under the action listener for the book method, I have this:

Everytime the book button is clicked a brand new thread is spawned to perform book and then refresh the JTable. For one, with my GUI, once a row is booked with a customerid, the book button becomes disabled, however I wonder if Sun will test outside of that. So am I approaching this correctly? Do I need to figure out something else to use for a map value? Here's my current code:



I don't mean to be repetitive, as this goes along with my other post. Thanks guys. I appreciate it!
[ January 13, 2005: Message edited by: Daniel Simpson ]

SCJP 1.4<br />SCJD 1.4
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
First on the client side, all modifications to the GUI state must be made from the Event Dispatch Thread, your worker thread must not call methods like setEnabled, you should use SwingUtilities.invokeLater().

Secondly, the checking for multiple locks should be in the server, since this is just the simplest solution to the deadlock problem. Other solutions such as requiring locks in ascending order, or detecting deadlock by checking if a client that requires a resource we have locked already has this resource locked could be implemented in its place on the server.
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
Originally posted by peter wooster:
First on the client side, all modifications to the GUI state must be made from the Event Dispatch Thread, your worker thread must not call methods like setEnabled, you should use SwingUtilities.invokeLater().

Secondly, the checking for multiple locks should be in the server, since this is just the simplest solution to the deadlock problem. Other solutions such as requiring locks in ascending order, or detecting deadlock by checking if a client that requires a resource we have locked already has this resource locked could be implemented in its place on the server.

Sorry, I wasn't very clear with my question. All of these tests were done in local mode (I'm using locking in local mode). My lock method and lock for multiple tests is all in my Data class in my db package. Maybe for my socket networking, have the server assign each socket an id? (Maybe an incrementing number). And when the socket sends a request (refer to my other reply to you) it can also send its id along to be used and checked.
So when my server calls the book method (lock-read-verify-update-delete) it could do something like given that id is a String. Also, I changed my code with the worker thread and invokeLater. Does this look correct now?


Thanks!
Dieskun Koper
Ranch Hand

Joined: Aug 15, 2004
Posts: 85
Some methods that modify GUI state, in particular the setText and setEnabled methods that you use, do not need to be run from the AWT thread. Some methods are safe, some or not. Read the javadocs or even look at the source.

Regarding your use of SwingUtilities.invokeLater, it is wrong
In your code you are creating a worker thread, and have its results processing scheduled on the AWT thread. These threads run concurrently, i.e. your GUI could be updated before your server has returned the results! Make sure you schedule your results processing thread to run after the server returns with the results.
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
Originally posted by Dieskun Koper:
Some methods that modify GUI state, in particular the setText and setEnabled methods that you use, do not need to be run from the AWT thread. Some methods are safe, some or not. Read the javadocs or even look at the source.

Regarding your use of SwingUtilities.invokeLater, it is wrong
In your code you are creating a worker thread, and have its results processing scheduled on the AWT thread. These threads run concurrently, i.e. your GUI could be updated before your server has returned the results! Make sure you schedule your results processing thread to run after the server returns with the results.


I'm confused, so it should just be reversed, or am I missing the whole point? Should it be:


Instead of my previous implementation:

Or am I just terribly confused?
Dieskun Koper
Ranch Hand

Joined: Aug 15, 2004
Posts: 85
You are terribly confused.
Your fixed version still creates two threads that could run simultaneously. You need the one to start when the other is finished (i.e. schedule the AWT thread right after the server comes back with the results).
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
Originally posted by Dieskun Koper:
You are terribly confused.
Your fixed version still creates two threads that could run simultaneously. You need the one to start when the other is finished (i.e. schedule the AWT thread right after the server comes back with the results).

hehehe Can you show me some code to help me understand? or alter mine to show me what i'm doing wrong and what i should do.
[ January 13, 2005: Message edited by: Daniel Simpson ]
Dieskun Koper
Ranch Hand

Joined: Aug 15, 2004
Posts: 85


Of course you'd want to catch exceptions from the server and notify the user about them from the AWT thread too.
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
Originally posted by Dieskun Koper:


Of course you'd want to catch exceptions from the server and notify the user about them from the AWT thread too.

Thanks for the help, Dies! Now I understand. I put little sys outs everywhere to see which thread was running it, and it all works great. Thanks!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Worker Threads