The client has a JTree component, originally it loaded all the data from server. In that case, the user needs to wait a while before the main frame visible. So I decide to load the data dynamically. When createGUI, I just load the first level data, then show the main frame to the user. At that time, I start a SwingWorker to load other data. After finished, modify the TreeModel in EDT.It will take about 15 seconds to load all the data. It looks OK. But one thing lefts, when the user expand a level one tree node, it's better to load the nodes under that node first.
Although the tree data is not huge, so when a user tries to expand one node, it actually already finishes its loading work. But as the data grows huge, my program will not be capable.
As far as I know, we can set priorities of threads but there is no guarantee that it would work as we expect. Thread scheduling depends on the operating system underlying the JVM.
You are doing sound, I believe.
Joined: Jan 28, 2005
Originally posted by Adeel Ansari: As far as I know, we can set priorities of threads but there is no guarantee that it would work as we expect. Thread scheduling depends on the operating system underlying the JVM.
You are doing sound, I believe.
Thanks Adeel. Now I just use one worker thread to load remaining data. For example there is a queue [node1, 2, 3...], my worker thread gather data under these nodes in order. But When a user expand node20, how do I suspend the running work and switch to node20?
Create a thread for every node, it seems not good.
Joined: Aug 15, 2004
Originally posted by Louis Wang: Create a thread for every node, it seems not good.
Indeed, it would be absurd. Why don't you do what you are doing and spin a new thread on call? Is it making sound to you?
Can you just keep a flag to know whether 20 has been started yet? If the user selects 20 and it hasn't been started yet, just start it. When the queue works down to 20 it will find 20 has been started and not try to start it again. That was an awfully long sentence with only about 4 different words in it. Did it make any sense?
I don't know what kind of operations go on during building nodes. If there's anything with some latency, like reading disk or network, you could run your queue of tasks on several threads with an Executor. But if you're just creating Swing widgets from data already in memory, more threads probably won't help.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Trying to explain what James said (provided my frequency matched with him ) The point is that you would not create a new thread for every node but would create a new thread for every user action(user expanding a node.) The process remains same whether the user opens the first level node or 10th level node. What you do is load the first level childs below the expanded node and spawn a thread to fetch the lower level childrens (till one level i guess) (Well this is what you are doing but i just have the habbit of writing alot ) Your tree object in the widget however takes care at the node level whether it already has the data for the node or not. If not, then it accepts the data update request by a thread else it ignores. (If you also allow updates to the data from some other source then you have to provide a flag to the data update method, which "force"s the data update) The above also assumes that the worker thread updates the tree one node at a time. It does not override the entire structure in one go. The above logic will disappoint some workers, in a case, when after working hard and getting the data for a node they get a shock that the data has already been retrieved by some other thread :roll: But this is ok as in effect it will be survival for the fastest!!! Who is the fastest will win!. That is what the user also wants ........ sppppppeeeeedddddd ... Oooopppsss ... most importantly your data structure should be thread-safe