commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bessie <tbes...@meez.com>
Subject Re: [configuration] How to get threadsafe subset() config in a threadsafe way?
Date Tue, 13 Mar 2012 18:05:22 GMT
That's a possibility which I'll look into.

In the meantime, after initializing our main Configuration wrapper object
with all of our static configuration data, I copy slices of it to static
maps that I know will never change, and provide convenience accessors to
those maps' data.  Since the calls that access the data placed in these new
maps were the only ones asking for slices of config data, this eliminates
our problem.  I was just hoping for a more elegant solution.  But at least
this way there's no locks necessary.

I'll take a look at your suggestions, however - thanks much!

A nice feature in the future could be something like
ConfigurationUtils.getSynchronizedInstance(Configuration), for example.
 I'm sure it's been discussed before. :-)

- Tim

On Tue, Mar 13, 2012 at 1:43 AM, Luc Maisonobe <Luc.Maisonobe@free.fr>wrote:

> Le 13/03/2012 07:34, Tim Bessie a écrit :
> > Hi all...
>
> Hi Tim,
>
> >
> > So we're keeping some config information CompositeConfiguration object,
> and
> > we need to get subsets of this configuration data.
> >
> > When I call .subset(...), and then do some checks on the subset
> (isEmpty(),
> > etc.), I sometimes get ConcurrentModificationExceptions.  I'm not sure
> > what's modifying the underlying configuration, although we do have
> > occasional setting of configuration values throughout the running of our
> > app.
> >
> > What would be *ideal* would be to:
> >
> > 1. NOT have to synchronize every access to the configuration object,
> since
> > we have a high-volume application
> > 2. To allow read and write operations to happen to the configuration
> object
> > without worrying about ConcurrentModificationExceptions
> > 3. To be able to call .subset(...) on the configuration object and 1) not
> > risk a ConcurrentModificationException during this operation, and 2) get
> a
> > COPY of the subset back, so that further operations on the subset don't
> > risk ConcurrentModificationExceptions
> >
> > Does anyone know of a way to do this?  Or is the ONLY way to guarantee
> lack
> > of CMEs to synchronize EVERY access (reads, writes, subsets, iterations,
> > etc.)?
>
> Perhaps you could try java.util.concurrent.locks.ReadWriteLock ? You
> would have to put the protection by yourself so it may require lots of
> code wrapping. One of the good thins is that it allows concurrent read
> (but when a write occurs, only one thread can write and reads are blocked).
>
> Luc
>
> >
> > If this is the case, how have others dealt with situations like ours,
> where
> > you do mostly just reads on a Configuration object, but very occasional
> > writes, and need to take subsets, and need to avoid exceptions while
> doing
> > this?  With a high volume app, synchronizing every access would slow
> things
> > waaaaaay down, thus my question.
> >
> > - Tim
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>


-- 

Tim Bessie
Meez, Inc.
tbessie@meez.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message