On 06/05/15 11:41, David Holmes wrote:
I don't think you want to de-synchronize the load* methods - you don't
want two threads calling load concurrently. But that then raises the
problem of concurrent modification while a load is in progress.
Synchronization ensures serialization and by removing it you have done
more than just avoid deadlocks.
I think this needs a more careful examination of the expected/desired
concurrent interactions between different methods. It may be that
simply not utilizing the synchronized Hashtable methods is sufficient
to resolve the deadlock, while still providing reasonable
serialization via the existing synchronized Properties methods - or it
may not. But allowing concurrent modifications will change behaviour
in an unexpected, and incompatible way, in my opinion.
David
-----
Hi David,
You say: "It may be that simply not utilizing the synchronized Hashtable
methods is sufficient to resolve the deadlock, while still providing
reasonable serialization via the existing synchronized Properties
methods - or it may not".
How do you propose to not utilize synchronized Hashtable methods? By not
utilizing Properties at all? This may be difficult to achieve as most
system configuration is specified as system Properties.
What I meant was to continue to delegate to the CHM to replace the
inherited Hashtable methods, but to keep the synchronized on the
Properties specific methods.
What about changing load0 to return a plain HashMap?
Then you could transfer the HashMap content into the CHM in
one go - that's the only part that really needs to be protected
against concurrent modification, isn't it?
The PropertiesDefaultHandler could also be changed to use
an intermediate HashMap object as well.
There would be a small compatibility issue however if some
subclass of Properties has some special logic for the case
where a property is declared twice (for instance, if it
overrides put() to merge values)...
best regards,
-- daniel
