# How to rollback/abort candidateCommit failed transaction

**URL:** <https://dmap-community.ductus.global/t/how-to-rollback-abort-candidatecommit-failed-transaction/3775>\
**Category:** CDB and CDB API\
**Created:** [August 17, 2021, 3:24am UTC](https://dmap-community.ductus.global/t/how-to-rollback-abort-candidatecommit-failed-transaction/3775 "2021-08-17T03:24:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![venkonan](https://avatars.discourse-cdn.com/v4/letter/v/a183cd/32.png) [@venkonan](https://dmap-community.ductus.global/u/venkonan)\
**Post date:** [August 17, 2021, 3:24am UTC](https://dmap-community.ductus.global/t/how-to-rollback-abort-candidatecommit-failed-transaction/3775/1 "2021-08-17T03:24:13Z")

</div>

Hi,

I’ve use case where I want to rollback the configs if maapi.candidateCommit() is failed.  
Here are the steps we perform.

1. Push configs without candidate db lock
2. Transaction completed successfully (applyTransaction and finishTransaction)
3. Execute Mappi.commitCandidate

While executing Maapi.candidateCommit, getting some access denied error due to nacm rule configured to deny for a particular path. Now due to this we fail the request, but configs are still present in candidate DB. We can use candidateReset method to copy the running into Candidate DB. But we don’t know what other configs are present in candidate DB as we don’t lock it before pushing configs.  
Is there a way to rollback only a specific transaction configs and keep the rest in candidate?  
Also is there a way an api to copy running into Candidate without discarding existing changes in Candidate?

Thanks,  
-Venkat

---

<div class="post-metadata">

**Author:** ![cohult](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/cohult/32/221_2.png) [@cohult](https://dmap-community.ductus.global/u/cohult)\
**Post date:** [August 17, 2021, 9:11am UTC](https://dmap-community.ductus.global/t/how-to-rollback-abort-candidatecommit-failed-transaction/3775/2 "2021-08-17T09:11:55Z")

</div>

Hi,

ConfD’s candidate + confirmed commit implementation is described by the NETCONF RFC 6241:

> **[RFC 6241: Network Configuration Protocol (NETCONF)](https://datatracker.ietf.org/doc/html/rfc6241#section-8.3)**
>
> The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration...

> **[RFC 6241: Network Configuration Protocol (NETCONF)](https://datatracker.ietf.org/doc/html/rfc6241#section-8.4)**
>
> The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration...

Quoting the RFC:

> The candidate configuration can be shared among multiple sessions.  
> Unless a client has specific information that the candidate  
> configuration is not shared, it MUST assume that other sessions are  
> able to modify the candidate configuration at the same time. It is  
> therefore prudent for a client to lock the candidate configuration  
> before modifying it.

Regarding confirmed commit:

> For shared configurations, this feature can cause other configuration  
> changes (for example, via other NETCONF sessions) to be inadvertently  
> altered or removed, unless the configuration locking feature is used  
> (in other words, the lock is obtained before the   
> operation is started). Therefore, it is strongly suggested that in  
> order to use this feature with shared configuration datastores,  
> configuration locking SHOULD also be used.

> [@venkonan](#):
>
> Is there a way to rollback only a specific transaction configs and keep the rest in candidate?

No

> [@venkonan](#):
>
> Also is there a way an api to copy running into Candidate without discarding existing changes in Candidate?

No

Implementing some external database that does what you describe is not recommended if you want to stay RFC 6241 compliant. If you want to diverge from the RFC, you are on your own.

---

<div class="post-metadata">

**Author:** ![venkonan](https://avatars.discourse-cdn.com/v4/letter/v/a183cd/32.png) [@venkonan](https://dmap-community.ductus.global/u/venkonan)\
**Post date:** [August 17, 2021, 5:41pm UTC](https://dmap-community.ductus.global/t/how-to-rollback-abort-candidatecommit-failed-transaction/3775/3 "2021-08-17T17:41:00Z")

</div>

Looks like ConfirmedCommit also rollbacks all other configs (configs pushed by some other client) present in candidate DB?  
Is ConfirmedCommit and candidateReset operations produces the same result?
