One of the key things that are a top priority in the development of Configuration Manager is to guarantee the target system's consistency after a snapshot deployment. To achieve this CMJ needs to properly handle any situation, e.g. if an unexpected error occurs, and make sure either the whole configuration was deployed or none of it in a transactional manner.
In version 3.6 CMJ introduced a custom roll-back strategy in case a snapshot deployment fails.
Until version 3.5.x CMJ relied on Jira's native transactions to rollback the uncommitted changes and all changes from deployment were performed within a single transaction. However, this leads to several major problems for larger deployments:
Jira's internal configuration caches are not transaction aware and are not automatically updated when configuration objects are added and other configuration changes depend on it. We worked around this problem by doing on-demand cache refreshes in case of a lookup failure. For more information review this issue - https://jira.atlassian.com/browse/JRA-38550
Jira doesn't officially support configuration changes from within a transaction. Since Jira 7.x the cache refreshes are performed using a new DB connection and there is no way to use newly added configuration objects from within the same transaction. For more information - https://jira.atlassian.com/browse/JRA-59733
CMJ implements a rollback strategy that will revert all configuration changes in the case of an error and leave the system in the initial state (before the deployment was started).
Deployment cancellation The rollback occurs only when CMJ has detected configuration errors. So, be aware that once the issue data import process has been initiated, you won’t be able to cancel it or roll it back. |