question on concurrent HashMap

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

question on concurrent HashMap

Amarnath Nanduri
I am currently using a concurrent hashmap to act as shared memory between different threads. I think I might be doing something wrong and would appreciate your help and guidance on this.
 
The scenario is:
A manager class fires up a bunch of database objects (implementing the Callable interface)  every one minute (in a Timer task) and gets back the immutable data objects.
//sample code
ExecutorService.invokeAll(database objects implementing Callable interface).
 
The manager then updates a concurrent HashMap with these data objects.
 
The gui components request the manager for the concurrent HashMap and each gui component asks for its own data object out of the cncurrent hash map. All gui components are in a single swing timer that fires up an event once every minute and asks the gui components to get their data objects.
 
Both Timer Task and Swing Timer are fired every one minute. I currently guess the amount of time delay I need (set to 30 seconds)  (to get the data from the database and populate the concurrent hash map) before the swing timer fires an event for the gui components to fetch from the concurrent hash map.
 
I have a feeling that I am doing something wrong here, but can't pinpoint the exact cause. One question that bothers me is that how can I make the Timer Task (in manager) and Swing Timer (controlling the gui components) be in step. i.e only after the concurrent hashmap is populated by the manager, do I want the swing timer firing up to allow the gui components to get their data.
 
Is there a way for the gui components to wait till their data object is put in the concurrent hash map, before they attempt to retreive the data from the concurrent hashmap?
 
Thank you for your time and patience.
 
Regards,
Amar..


Everyone is raving about the all-new Yahoo! Mail.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question on concurrent HashMap

Joe Bowbeer
On 11/2/06, Amarnath Nanduri <[hidden email]> wrote:
> [...]
> One question that bothers me is that how can I make the
> Timer Task (in manager) and Swing Timer (controlling the gui
> components) be in step. i.e only after the concurrent hashmap
> is populated by the manager, do I want the swing timer firing up
> to allow the gui components to get their data.
>

The timer task in manager can schedule a task on Swing's event thread
using EventQueue.invokeLater (aka SwingUtilities.invokeLater).  This
is the mechanism employed by SwingWorker.  In your case, the task
would query the cache for the latest results and update the UI.

If the contents of the cache are interrelated then you may need to
employ a split-model technique so that your UI depicts a valid
instance of the cached state - and not some transitional state.

More:

SwingWorker is reconstructed in JCiP.

The second example in my Swing Threads article uses the split-model technique:

http://java.sun.com/products/jfc/tsc/articles/threads/threads3.html


> Is there a way for the gui components to wait till their data object
> is put in the concurrent hash map, before they attempt to retrieve
> the data from the concurrent hashmap?
>

Not on the Swing GUI side - without blocking the event thread.
Polling in the event thread (via Swing Timer) would be the only way.

--Joe


On 11/2/06, Amarnath Nanduri <[hidden email]> wrote:

> I am currently using a concurrent hashmap to act as shared memory between
> different threads. I think I might be doing something wrong and would
> appreciate your help and guidance on this.
>
> The scenario is:
> A manager class fires up a bunch of database objects (implementing the
> Callable interface)  every one minute (in a Timer task) and gets back the
> immutable data objects.
> //sample code
> ExecutorService.invokeAll(database objects implementing Callable interface).
>
> The manager then updates a concurrent HashMap with these data objects.
>
> The gui components request the manager for the concurrent HashMap and each
> gui component asks for its own data object out of the cncurrent hash map.
> All gui components are in a single swing timer that fires up an event once
> every minute and asks the gui components to get their data objects.
>
> Both Timer Task and Swing Timer are fired every one minute. I currently
> guess the amount of time delay I need (set to 30 seconds)  (to get the data
> from the database and populate the concurrent hash map) before the swing
> timer fires an event for the gui components to fetch from the concurrent
> hash map.
>
> [...]
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question on concurrent HashMap

Amarnath Nanduri
Hi Joe:

   I thank you for your reply. I use the split model (infact I had already seen the article you mentioned a few months back and use that technique in my application whenever end user demands to see detailed data and it is got from the database i.e it is by demand).

The manager is not part of the GUI and is infact a singleton in the application. I figured a singleton to schedule the database calls in a timer, to get the data and populate the concurrent hash map would be an ideal approach.

The way the application flows currently is:
1.   create a connection pool, and create the manager.
2.   manager creates the timer task and schedules the database calls every 60 seconds.
3    manager populates the concurrent hash map.
4    gui swing timer is created with an initial delay of 10 seconds.
5    swing timer event fires up every 60 seconds and gui components ask the manager for the concurrent hash map.
6    gui components get their respective data and displays the information.

I feel my weak link is between 3 & 4. By trail and error I came up with the 10 second delay in 4.

The assumed time line in minute/seconds is  :
0.00 - start the application
0.05 - create the connection pool  ( takes 5 seconds)
0.07 - create the manager and the timer.
0.08 - manager fires up the timer for database calls. timer fires up every 60 seconds.
0.10 - manager starts populating the concurrent hash map.
0.11 - gui creates swing timer with initial delay of 10 seconds.
0.41 - fire up the swing timer. timer fires up every 60 seconds.
0.42 - gui components access the concurrent hash map
1.08 - manager timer fires up and makes the database calls.
1.10 - manager populates the concurrent hash map
1.41 - swing timer fires up
 
Based on this timeline ( i made some assumptions) do you foresee any problems with the approach? I assume the database will be up and running all the time my application runs.

Many thanks,
Amar..

Joe Bowbeer <[hidden email]> wrote:
On 11/2/06, Amarnath Nanduri wrote:
> [...]
> One question that bothers me is that how can I make the
> Timer Task (in manager) and Swing Timer (controlling the gui
> components) be in step. i.e only after the concurrent hashmap
> is populated by the manager, do I want the swing timer firing up
> to allow the gui components to get their data.
>

The timer task in manager can schedule a task on Swing's event thread
using EventQueue.invokeLater (aka SwingUtilities.invokeLater). This
is the mechanism employed by SwingWorker. In your case, the task
would query the cache for the latest results and update the UI.

If the contents of the cache are interrelated then you may need to
employ a split-model technique so that your UI depicts a valid
instance of the cached state - and not some transitional state.

More:

SwingWorker is reconstructed in JCiP.

The second example in my Swing Threads article uses the split-model technique:

http://java.sun.com/products/jfc/tsc/articles/threads/threads3.html


> Is there a way for the gui components to wait till their data object
> is put in the concurrent hash map, before they attempt to retrieve
> the data from the concurrent hashmap?
>

Not on the Swing GUI side - without blocking the event thread.
Polling in the event thread (via Swing Timer) would be the only way.

--Joe


On 11/2/06, Amarnath Nanduri wrote:

> I am currently using a concurrent hashmap to act as shared memory between
> different threads. I think I might be doing something wrong and would
> appreciate your help and guidance on this.
>
> The scenario is:
> A manager class fires up a bunch of database objects (implementing the
> Callable interface) every one minute (in a Timer task) and gets back the
> immutable data objects.
> //sample code
> ExecutorService.invokeAll(database objects implementing Callable interface).
>
> The manager then updates a concurrent HashMap with these data objects.
>
> The gui components request the manager for the concurrent HashMap and each
> gui component asks for its own data object out of the cncurrent hash map.
> All gui components are in a single swing timer that fires up an event once
> every minute and asks the gui components to get their data objects.
>
> Both Timer Task and Swing Timer are fired every one minute. I currently
> guess the amount of time delay I need (set to 30 seconds) (to get the data
> from the database and populate the concurrent hash map) before the swing
> timer fires an event for the gui components to fetch from the concurrent
> hash map.
>
> [...]
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


Get your email and see which of your friends are online - Right on the new Yahoo.com
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question on concurrent HashMap

David Holmes-3
Hello Amar,
 
I think what Joe was suggesting was a "push" style approach whereby the timer task, after getting updates from  the database, posts an event to the Swing event thread that then has each component update itself with the latest data from the map. That way there is no need for the UI updates to wait for fresh data.
 
Cheers,
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Amarnath Nanduri
Sent: Friday, 3 November 2006 3:34 PM
To: Joe Bowbeer; [hidden email]
Subject: Re: [concurrency-interest] question on concurrent HashMap

Hi Joe:

   I thank you for your reply. I use the split model (infact I had already seen the article you mentioned a few months back and use that technique in my application whenever end user demands to see detailed data and it is got from the database i.e it is by demand).

The manager is not part of the GUI and is infact a singleton in the application. I figured a singleton to schedule the database calls in a timer, to get the data and populate the concurrent hash map would be an ideal approach.

The way the application flows currently is:
1.   create a connection pool, and create the manager.
2.   manager creates the timer task and schedules the database calls every 60 seconds.
3    manager populates the concurrent hash map.
4    gui swing timer is created with an initial delay of 10 seconds.
5    swing timer event fires up every 60 seconds and gui components ask the manager for the concurrent hash map.
6    gui components get their respective data and displays the information.

I feel my weak link is between 3 & 4. By trail and error I came up with the 10 second delay in 4.

The assumed time line in minute/seconds is  :
0.00 - start the application
0.05 - create the connection pool  ( takes 5 seconds)
0.07 - create the manager and the timer.
0.08 - manager fires up the timer for database calls. timer fires up every 60 seconds.
0.10 - manager starts populating the concurrent hash map.
0.11 - gui creates swing timer with initial delay of 10 seconds.
0.41 - fire up the swing timer. timer fires up every 60 seconds.
0.42 - gui components access the concurrent hash map
1.08 - manager timer fires up and makes the database calls.
1.10 - manager populates the concurrent hash map
1.41 - swing timer fires up
 
Based on this timeline ( i made some assumptions) do you foresee any problems with the approach? I assume the database will be up and running all the time my application runs.

Many thanks,
Amar..

Joe Bowbeer <[hidden email]> wrote:
On 11/2/06, Amarnath Nanduri wrote:
> [...]
> One question that bothers me is that how can I make the
> Timer Task (in manager) and Swing Timer (controlling the gui
> components) be in step. i.e only after the concurrent hashmap
> is populated by the manager, do I want the swing timer firing up
> to allow the gui components to get their data.
>

The timer task in manager can schedule a task on Swing's event thread
using EventQueue.invokeLater (aka SwingUtilities.invokeLater). This
is the mechanism employed by SwingWorker. In your case, the task
would query the cache for the latest results and update the UI.

If the contents of the cache are interrelated then you may need to
employ a split-model technique so that your UI depicts a valid
instance of the cached state - and not some transitional state.

More:

SwingWorker is reconstructed in JCiP.

The second example in my Swing Threads article uses the split-model technique:

http://java.sun.com/products/jfc/tsc/articles/threads/threads3.html


> Is there a way for the gui components to wait till their data object
> is put in the concurrent hash map, before they attempt to retrieve
> the data from the concurrent hashmap?
>

Not on the Swing GUI side - without blocking the event thread.
Polling in the event thread (via Swing Timer) would be the only way.

--Joe


On 11/2/06, Amarnath Nanduri wrote:

> I am currently using a concurrent hashmap to act as shared memory between
> different threads. I think I might be doing something wrong and would
> appreciate your help and guidance on this.
>
> The scenario is:
> A manager class fires up a bunch of database objects (implementing the
> Callable interface) every one minute (in a Timer task) and gets back the
> immutable data objects.
> //sample code
> ExecutorService.invokeAll(database objects implementing Callable interface).
>
> The manager then updates a concurrent HashMap with these data objects.
>
> The gui components request the manager for the concurrent HashMap and each
> gui component asks for its own data object out of the cncurrent hash map.
> All gui components are in a single swing timer that fires up an event once
> every minute and asks the gui components to get their data objects.
>
> Both Timer Task and Swing Timer are fired every one minute. I currently
> guess the amount of time delay I need (set to 30 seconds) (to get the data
> from the database and populate the concurrent hash map) before the swing
> timer fires an event for the gui components to fetch from the concurrent
> hash map.
>
> [...]
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


Get your email and see which of your friends are online - Right on the new Yahoo.com

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question on concurrent HashMap

Joe Bowbeer
On 11/2/06, David Holmes <[hidden email]> wrote:
>
> I think what Joe was suggesting was a "push" style approach whereby
> the timer task, after getting updates from the database, posts an event
> to the Swing event thread that then has each component update itself
> with the latest data from the map. That way there is no need for the UI
> updates to wait for fresh data.
>

Yes.

One way to implement this while still preserving the beneficial
separation of UI from data model would be to add support for listeners
to the manager.

Then the UI could register a special "relaying" listener that, when
notified, would schedule (i.e., invokeLater) the appropriate update
task on the event thread.

--Joe
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question on concurrent HashMap

tpeierls
And see section 9.4 of Java Concurrency in Practice for more on "push" and thread-safe data models.

--tim

On 11/3/06, Joe Bowbeer <[hidden email]> wrote:
On 11/2/06, David Holmes <[hidden email]> wrote:
>
> I think what Joe was suggesting was a "push" style approach whereby
> the timer task, after getting updates from the database, posts an event
> to the Swing event thread that then has each component update itself
> with the latest data from the map. That way there is no need for the UI
> updates to wait for fresh data.
>

Yes.

One way to implement this while still preserving the beneficial
separation of UI from data model would be to add support for listeners
to the manager.

Then the UI could register a special "relaying" listener that, when
notified, would schedule (i.e., invokeLater) the appropriate update
task on the event thread.

--Joe
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question on concurrent HashMap

Amarnath Nanduri
This is fantastic. I will definitely modify my application to follow this approach. Many thanks to all of you for your suggestions.
 
Regards,
Amar..

Tim Peierls <[hidden email]> wrote:
And see section 9.4 of Java Concurrency in Practice for more on "push" and thread-safe data models.

--tim

On 11/3/06, Joe Bowbeer <[hidden email]> wrote:
On 11/2/06, David Holmes <[hidden email]> wrote:
>
> I think what Joe was suggesting was a "push" style approach whereby
> the timer task, after getting updates from the database, posts an event
> to the Swing event thread that then has each component update itself
> with the latest data from the map. That way there is no need for the UI
> updates to wait for fresh data.
>

Yes.

One way to implement this while still preserving the beneficial
separation of UI from data model would be to add support for listeners
to the manager.

Then the UI could register a special "relaying" listener that, when
notified, would schedule (i.e., invokeLater) the appropriate update
task on the event thread.

--Joe
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest



Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest