commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [configuration] How to get threadsafe subset() config in a threadsafe way?
Date Tue, 13 Mar 2012 08:43:27 GMT
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).


> 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:
For additional commands, e-mail:

View raw message