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<[email protected]>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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
