views:

114

answers:

1

I have referenced this previous question as well as other sources, but cannot get CountDownLatch to work correctly.

Background: mainFrame creates new Frame called dataEntryFrame. When dataEntryFrame "Submit" button is clicked, record added to database and dataEntryFrame disposed. At this point, mainFrame should clear and reload a jList that shows all records.

Issue: When dataEntryFrame loads, java freezes, dataEntryFrame components never load. I cannot get past this part... then, in the DataEntryFrame, CountDownLatch should only decrements after the submit button is clicked, successfully adds a record to a database table, and disposes itself. Or when the user clicks cancel...

Code: From MainFrame

clearList();
CountDownLatch dataEntryDone = new CountDownLatch(1);
DataEntryFrame f = new DataEntryFrame(dataEntryDone);
Thread newThread = new Thread(f);
newThread.start();
dataEntryDone.await();
reLoadList();

Code: From DataEntryFrame

public void run(){
initComponents();
loadOtherData();
this.setVisible(true);
}
void submit(){
addRecord();
this.dispose()
dataEntryDone.countDown();
}
+2  A: 

Use of a new thread for the dataEntryFrame and blocking the mainFrame go against the Swing threading model. In Swing, all calls to UI components in Swing must take place on the Event Dispatch Thread. To verify that this is happening during development, you can install a repaint manager that throws an exception if it detects that UI components are being used from another thread. See FEST - Testing that access to GUI components is done in the EDT. To ensure that something happens on the EDT, you use SwingUtilities.invokeAndWait/invokeLater.

Your main frame doesn't (and shouldn't!) have to wait for the data entry frame, instead of the CountDownLatch, have your data entry frame fire an event to the MainFrame when it is done, so that the MainFrame can take appropriate action, such as refreshing the list.

Just to muddy the waters still further, saving data to the database and fetching the data for the list should ideally not be done on the event dispatch thread. Instead, use a SwingWorker to perform these operations in their own thread. However, unlike the rule that all UI components must be accessed from the EDT, this rule of background processing is not hard and fast, but is recommended to maintain a responsive UI - if data transfer to/from the db takes any length of time and it's done on the UI thread (EDT) then the UI will freeze.

See

mdma
Thanks for the helpful words, mdma, and Noel. I started looking into the EDT and Swing Worker after Noel's request for more code. SwingWorker seems like the route to go vs CountDownLatch. You are right too that the database queries could be done similarly...I don't see a performance hit now but with larger scale I am sure this could happen. I found this too, which may be useful: http://java.sun.com/docs/books/tutorial/uiswing/concurrency/dispatch.htmljavax.swing.SwingUtilities.isEventDispatchThread()
Brian
Now that I think of it, this was a case of now knowing what I did not know... so thanks again.
Brian
Your welcome. It's hardly surprising you missed this - first java gets a multi-threaded GUI toolkit - the AWT, and then later this is extended into Swing, without the multi-threaded support.
mdma