History

sleto-it 0ba532b16a Doc - Replication Refactor - Part 1 (#4555 ) Next steps after DC2DC and Cluster doc improvements: - We refactor replication sections and make more intuitive separation between Master/Slave and the new Active Failover in 3.3 - We create corresponding sections for Master/Slave and Active Failover in the Administration and Deployment chapters, as well as in the Scalability chapter, where these "modes" are introduced - We touch and improve the "Architecture" chapter as well, where some architecture info have to be placed - We reorg the TOC having in more "logical" order: -- Deployment -- Administration -- Security -- Monitoring -- Troubleshooting - We adds parts in the TOC - We add toc per pages, using page-toc plugin - We also put close together "Scalability" and "Architecture" chapters, preliminary steps of further improvements / aggregation - We improve swagger Internal Ref: - https://github.com/arangodb/planning/issues/1692 - https://github.com/arangodb/planning/issues/1655 - https://github.com/arangodb/planning/issues/1858 - https://github.com/arangodb/planning/issues/973 (partial fix) - https://github.com/arangodb/planning/issues/1498 (partial fix)	2018-02-28 12:23:19 +01:00
..
README.md	Doc - Replication Refactor - Part 1 (#4555 )	2018-02-28 12:23:19 +01:00

Doc - Replication Refactor - Part 1 (#4555 )

Next steps after DC2DC and Cluster doc improvements:

- We refactor replication sections and make more intuitive separation between Master/Slave and the new Active Failover in 3.3
- We create corresponding sections for Master/Slave and Active Failover in the Administration and Deployment chapters, as well as in the Scalability chapter, where these "modes" are introduced
- We touch and improve the "Architecture" chapter as well, where some architecture info have to be placed
- We reorg the TOC having in more "logical" order:
-- Deployment
-- Administration
-- Security
-- Monitoring
-- Troubleshooting
- We adds parts in the TOC
- We add toc per pages, using page-toc plugin
- We also put close together "Scalability" and "Architecture" chapters, preliminary steps of further improvements / aggregation
- We improve swagger

Internal Ref:
- https://github.com/arangodb/planning/issues/1692
- https://github.com/arangodb/planning/issues/1655
- https://github.com/arangodb/planning/issues/1858
- https://github.com/arangodb/planning/issues/973 (partial fix)
- https://github.com/arangodb/planning/issues/1498 (partial fix)

2018-02-28 12:23:19 +01:00

README.md

Doc - Replication Refactor - Part 1 (#4555 )

2018-02-28 12:23:19 +01:00

README.md

HTTP Interface for Transactions

Transactions

ArangoDB's transactions are executed on the server. Transactions can be initiated by clients by sending the transaction description for execution to the server.

Transactions in ArangoDB do not offer separate BEGIN, COMMIT and ROLLBACK operations as they are available in many other database products. Instead, ArangoDB transactions are described by a JavaScript function, and the code inside the JavaScript function will then be executed transactionally. At the end of the function, the transaction is automatically committed, and all changes done by the transaction will be persisted. If an exception is thrown during transaction execution, all operations performed in the transaction are rolled back.

For a more detailed description of how transactions work in ArangoDB please refer to Transactions.

@startDocuBlock post_api_transaction