Re: Serious concurrency problems on fast systems
Kevin McMurtrie wrote:
The properties aren't immutable.
Martin Gregorie wrote:
But its unlikely that you'll want to change them frequently, regardless
of whether 'frequently' is defined in human or electronic terms.
The best feature of properties rather
than hard-coded values is being able to update them in an emergency
without server restarts.
So, why not design in the same sort of mechanism that is used by high
performance servers such as bind or Samba? IOW, store properties in read-
only objects and provide a method that reloads them on demand. It could
be an explicit command that's issued when a change is made or simply a
thread that scans for changes every minute or so and only makes changes
when a modification is detected.
Why are people so deucedly afraid of "new ImmutableThingie()"?
Kevin, you asked for advice. You've gotten good advice - make shared objects
immutable.
Even non-shared objects should mostly be immutable, unless they really,
really, really, really should be mutable by their inherent nature. Most of
the time, as in your properties case, you can get by with creation of a new
immutable object.
In in-between scenarios, like if you want slowly-changing properties, you
create one immutable shared object from a synchronized factory (that in this
case copies System.properties) at the top of a long operation.
System.properties is such the wrong place to put properties that change during
the life of the program. As you point out it's not designed for good
concurrency. Put those mutable properties somewhere else, like in a
ConcurrentHashMap as I've already suggested.
Sheesh.
--
Lew