commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [configuration] thread-safe?
Date Tue, 04 Nov 2003 07:53:47 GMT
Good reply Oliver.  Are you thinking of some sort of SingletonConfiguration
object that just has a single static Configuration object..  So, whether you
call it as SingletonCongifuration.getString("test.value") or create an
object singletonConfiguration.getString() you get the same thing?

Something to look at is an Avalon wrapper I tossed out in Fulcrum[1].  This
provides a "singleton" in terms of the Container being responsible for
returning just one instance of the object, verus loading multiple.  It seems
to me that as long as we are talking readonly, then it doesn't matter how
many threads read, correct?  And, if you want to write, just toss a
sychronize keyword?

Eric


[1]
http://jakarta.apache.org/turbine/fulcrum/fulcrum-configuration/index.html
> -----Original Message-----
> From: Oliver Heger [mailto:Oliver.Heger@t-online.de]
> Sent: Monday, November 03, 2003 9:00 PM
> To: Jakarta Commons Developers List
> Subject: Re: [configuration] thread-safe?
>
>
> Charles,
>
> as I see nobody of the commiters has answered you so far. Then I will
> try to give you a hint though I don't have written this code. So what
> follows need not to be 100% correct.
>
> Well, at the heart of the implementation of all so far existing
> Configuration classes is an instance of the class
> SequencedHashMap from
> common collections. So thread safety of [configuration] boils down to
> the thread-safety of this class. The documentation in [collections]
> states that the class is not thread safe, but this statement probably
> refers to manipulation in multiple threads and not to read
> only access.
> So it may be worth to ask the [collections] guys if read only
> access of
> a SequencedHashMap instance from multiple threads is safe.
>
> IMHO usage of ConfigurationFactory from a singleton is a good
> idea - if
> it comes out that thread-safety is guaranteed and access is
> read only. I
> think that is the easiest way of allowing application wide (okay:
> classloader wide) access to the configuration. Maybe it would
> make sense
> to support such a singleton like access directly in [configuration]?
>
> I hope I could help you.
>
> Oli
>
> Charles Crouch wrote:
>
> > Hi
> >
> > I'm looking to use the configuration package and wanted to
> wrap it in
> > my own Singleton e.g.
> > MyConfiguration.getInstance().getProperty(key). The
> > ConfigurationFactory, referencing various Properties files,
> would get
> > setup in the constructor of MyConfiguration.
> >
> > If I do not intend to add properties at run time, is it ok to use
> > MyConfiguration in a mutli-threaded environment, i.e. once the
> > ConfigurationFactory has been loaded up, is it safe for multiple
> > threads to retrieve properties at the same time.
> >
> > I'd really appreciate some advice if the Singleton pattern
> is not the
> > recommend approach. I'm trying to  centralise where the
> Configuration
> > is setup and also trying to ensure that the Properties files would
> > only get read in once, rather than each call to retrieve a property.
> >
> > Thanks in advance
> > Charles
> >
> > _________________________________________________________________
> > Sign-up for a FREE BT Broadband connection today!
> > http://www.msn.co.uk/specials/btbroadband
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message