Backing out a change request should be considered only as a last resort. If possible, correct the problem by immediately fixing and re-promoting the object. However, your course of action depends on the nature and severity of the problem, the scope of the original change request, the effects of its promotion, and what was backed up prior to applying that promotion.
The backout of change requests can change the behavior of one or many of your application systems. When backing out change requests, you must have a thorough understanding of the impact of the changes on users currently signed on to the TIBCO Object Service Broker system.
It is usually not desirable to make changes to application systems while users of those applications are signed on to TIBCO Object Service Broker. If you have users logged in, promotions could not complete correctly. For example, if a user is accessing a table that you want to promote, the promotion could fail due to locking problems. Procedures to help you coordinate promotions with user activity are provided in
Appendix A, User Access.
Backing out a change request can be a complex operation, especially if other change requests are dependent on the ones you want to back out. Like the sequence of promotions, the backout sequence is a matter that must be coordinated between change request creators and those who promote the change requests.