• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

Worker Threads

 
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!
 
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!
 
You can't have everything. Where would you put it?
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic