[concurrency-interest] Implementation of a global configurationcache

David Holmes davidcholmes at aapt.net.au
Mon Jun 15 06:52:57 EDT 2009


With regards to your visibility concerns either:

- static variables must be statically initialized; or else
- the cache must be initialized before any of the threads that use it are
started and there must be a happens-before relationship between the cache
initialization and the thread start; or else
- the variables must be volatile

David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Thejo Kote
  Sent: Monday, 15 June 2009 6:56 PM
  To: concurrency-interest at cs.oswego.edu
  Subject: [concurrency-interest] Implementation of a global
configurationcache


  Hi,

  I'm trying to improve the design of a global configuration cache which
currently consists of public static variables in a class. Something like -

  public final class ConfigCache {

      public static String val1;
      public static Map<Integer, MyObj> val2;

      public static initializeCache() {
          val1 = ....;
      }

  }

  I use the config values in other parts of the applications as
ConfigCache.val1 etc. The task performed by the application is highly
parallelizable and many threads read the configuration values. Some config
values don't change after initialization at start up and some (like val2)
are periodically (every 15 minutes) read from a database and updated in the
cache from a separate thread. I take advantage of the fact that writes to
and reads of references are always atomic when updating cache values in run
time.

  With that background -

  - Are the visibility characteristics of static and non-static variables
the same? Is it just sheer luck that the reading threads pick up the last
updated reference, and should they be declared as volatile?
  - I'm ensuring that no references escape by initializing the cache before
the application accepts requests, but using public static fields is not
ideal and does not provide the required encapsulation. Is there a standard
pattern for implementing such a configuration cache where many threads
constantly read values with an occasional write. Is a singleton object with
proper use of read write locks on the values that keep changing the right
solution?

  Thanks,
  Thejo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090615/21dca837/attachment.html>


More information about the Concurrency-interest mailing list