[wildfly-dev] Discarding the changed management model during operation rollback

Brian Stansberry brian.stansberry at redhat.com
Wed Jul 1 12:43:25 EDT 2015


tl;dr;

When an operation that has changed the management model is rolling back, 
the OperationStepHandlers processing the rollback see the model as it 
was at the arbitrary point when the rollback began. I propose changing 
this so they see things as they were prior to the first change to the model.

Long version:

When an operation mutates either the management Resource tree, or the 
registry of capabilities (together known as the management model), we 
clone the management model and thereafter that operation works on the 
clone. The clone is invisible to other callers until the operations 
successfully commits. When the operation commits, it publishes the clone 
and that becomes the official model.

I call this copy-on-write, publish-on-commit.

If the operation rolls back, the changed model is never published and 
the clone is just discarded when the operation execution returns.

However, while the operation is rolling back, all the 
OperationStepHandlers that are processing the rollback see the modified 
clone, not the original model. They are seeing arbitrarily incorrect data.

This hasn't been a problem up to now, as our standard OSHs get a copy of 
whatever part of the Resource tree they are going to modify and keep it 
for use in rollback. They don't need to re-read the management model to 
perform rollback.

But this doesn't work for the capability registry. If an OSH removes a 
capability and removes a service, and then in rollback tries to use the 
capability to figure out how to restore the service, it fails, as 
management model it can see still shows the capability as being removed.

To fix this, I propose discarding the cloned management model as soon as 
rollback begins. Thereafter, an OSH processing rollback will see the 
model as it was before the first modification. The removed capability 
will still be present.

I have a commit that does this at [1]. Running the testsuite with it 
shows no regressions. This doesn't surprise me, as our standard OSHs up 
to now have had no need to re-read the model during rollback.

[1] 
https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9aa514de08c01bf976be

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list