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

[Tomaž Cerar]

So if we are doing +1s, then
+1

:)

On Thu, Jul 2, 2015 at 9:49 AM, Kabir Khan <kabir.khan at jboss.com> wrote:

> Me too
> > On 1 Jul 2015, at 20:03, Jason Greene <jason.greene at redhat.com> wrote:
> >
> > I completely agree.
> >
> >> On Jul 1, 2015, at 11:43 AM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >>
> >> 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
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > --
> > Jason T. Greene
> > WildFly Lead / JBoss EAP Platform Architect
> > JBoss, a division of Red Hat
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150702/54784cb1/attachment-0001.html