[concurrency-interest] question on concurrent HashMap

David Holmes dcholmes at optusnet.com.au
Fri Nov 3 00:58:27 EST 2006


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: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Amarnath
Nanduri
  Sent: Friday, 3 November 2006 3:34 PM
  To: Joe Bowbeer; Concurrency-interest at cs.oswego.edu
  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 <joe.bowbeer at gmail.com> 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
    Concurrency-interest at altair.cs.oswego.edu
    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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20061103/c891b5da/attachment-0001.html 


More information about the Concurrency-interest mailing list