Suggestion on using SwingThreads to fetch data with Stateless Sessin Beans

Question

Hi,
I have developed a GUI application using Swing.
Using this GUI user will be able to view data (Tabular representation)fetched from database using Stateless session beans. In the application there will be two tabs and data should be fetched based on filtering parameters like Id which is a combo box. So if the user changes the comboBox selection, the data should be updated in two tabs irrespective of current tab focus.
Currently I'have not used any Threading concept while fetching data. I have made calls based on Tab focus. But plans to use SwingThread SwingUtilities class. But it has problems of asychronous communication. So if anyone has faced problems using swing thread for doing database access using stateless session beans can throw somelight on this to avoid problems which may come later.
In simpler terms using Swing threads have to make two or three EJB calls and fetch data from database and update the Table data.
Thanks.

Answer 1

Your user response time should not necessarily increase. You could load your data for the selected tab first and update the display after each response. This is simply showing information as soon as it becomes available rather than waiting for the entire operation (2 remote calls) to complete.
If you use 2 Threads you might get this anyway but should ensure that your EJB calls happen in parallel otherwise you should work out the best order for them yourself.
I'm not sure I'd say that you'd get synchronisation issues. You might get data issues whereby, as you rightly say, one of your calls returns an error. This shouldn't cause too many problems but you will need to make sure you've got suitable error-handling code and the ability to convey errors to the user.
Personally, if the calls were dependent on each other I'd make them one after another in the same Thread rather than trying to coordinate two concurrent remote calls.
If you're worried about the overhead of two remote calls in series then you can always expose another stateless session bean method that will perform both calls (or however many you want) for you in one remote call, thereby cutting down the overhead and simplifying your client development.
Hope this helps.