commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [configuration] How to get threadsafe subset() config in a threadsafe way?
Date Wed, 14 Mar 2012 20:24:52 GMT
Am 13.03.2012 19:05, schrieb Tim Bessie:
> 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

You are right, support for concurrent access to Configuration objects 
can certainly be improved.

Can you provide a stack trace of such a ConcurrentModificationException 
you receive occasionally?

Thanks
Oliver

>
> 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
>>
>>
>
>


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


Mime
View raw message