[ https://issues.jboss.org/browse/WFLY-6530?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-6530: ---------------------------------------- I'm going to move this to WFCORE because that's where the problem is. It's not specific to this particular attribute. I believe the problem is AbstractCollectionHandler L91, which should not be a simple context.readResource(ForUpdate). Instead the handler needs to create a "response" ModelNode, create a "read-attribute" operation, pass in those two params to add a step to execute that op, and then another step that uses the data in the now-populated response node to do the rest of the manipulation. Basically, calling context.readResource(ForUpdate) only works if the attribute value is stored in the Resource's internal model. In this case it is not; it's synthetically derived by reading the child resources. A twist is adding a step with the read-resource op is not going to acquire the controller lock before the read, so you could have a race where the read is done, then another op writes, changing the relevant model, and then the write executes, overwriting the other op's change. Sure, it's a 1 in 1,000,000,000 case, but the simple solution is to call context.acquireControllerLock before adding the steps if requiredReadWriteAccess == true. -- This message was sent by Atlassian JIRA (v6.4.11#64026)