Guard domain topology changes with separate locks from the controller lock -------------------------------------------------------------------------- Key: WFCORE-252 URL: https://issues.jboss.org/browse/WFCORE-252 Project: WildFly Core Issue Type: Sub-task Components: Domain Management Affects Versions: 1.0.0.Alpha12 Reporter: Brian Stansberry Labels: domain-mode Look into having a separate lock for the domain topology, and not using the exclusive controller lock to guard it. This requires great care though, as now there will be two separate locks involved in operation execution. We need to be certain that all code paths always acquire them in the same order or we'll be vulnerable to deadlocks. I believe the correct order should be 1) topology lock 2) controller lock. There are relatively few points where a topology lock would be needed, and I believe they are all at the outer edge of operation execution. So it's much simpler to control those points and ensure they always get topology before doing anything that could need the controller lock. Note it's possible 3 locks will be involved, one for host topology, one for server, and then the controller lock. Locking order needs to be thought about on a domain-wide basis, not just within a single process! This task will be more important once the feature discussed at http://lists.jboss.org/pipermail/wildfly-dev/2014-October/003241.html comes in, as that will result in numerous read operations that truly need the domain topology lock.