Overview
| Excerpt |
|---|
Fedora 4 supports the ability to wrap multiple REST API calls into a single transaction that can be committed or rolled back as an atomic operation. |
After retrieving a transaction resource using the RESTful HTTP API - Transactions, clients can send additional REST API calls within the scope of that transaction. After committing the transaction, the pending changes will be persisted in a single atomic operation. Validation, event-driven workflows, and other asynchronous operations are not triggered until the transaction is committed, which may provide a performance increase for some types of iterative tasks. Transactions can also be rolled back, as if they never occurred.
Example
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Create a transaction. In the response, the Location header will contain a path to the created transaction
...
API requests can be prefixed with the transaction identifier:
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
You can send most API requests scoped by the transaction. API requests that are not prefixed by a path to the node do not occur within the scope of a transaction and cannot be used (e.g. fcr:nodetypes, fcr:namespaces, etc)
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Until the transaction is committed, no other client will see the changes made within the scope of the transaction. After committing, the changes will be applied to the workspace and all clients will be able to see the change.
Fedora 4's transactions do NOT support checkpointing. After committing a transaction, it is closed, and any further operations on that transaction will be rejected.
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
The changes made within the scope of the transaction will be erased, and the transaction closed and removed.