Transactions in C8 have been designed with particular use cases in mind. They will be mainly useful for short and small data retrieval and/or modification operations.
The implementation is not optimized for very long-running or very voluminous operations, and may not be usable for these cases.
Data of ongoing transactions is stored in RAM. Transactions that get too big (in terms of number of operations involved or the total size of data created or modified by the transaction) will be committed automatically. Effectively this means that big user transactions are split into multiple smaller RocksDB transactions that are committed individually. The entire user transaction will not necessarily have ACID properties in this case. The actual data modification operations of a transaction are written to the write-ahead log and do not need to fit entirely into main memory.
Ongoing transactions will also prevent the write-ahead logs from being fully garbage-collected. Information in the write-ahead log files cannot be written to collection data files or be discarded while transactions are ongoing.
To ensure progress of the write-ahead log garbage collection, transactions should be kept as small as possible, and big transactions should be split into multiple smaller transactions.
Transactions in C8 cannot be nested, i.e. a transaction must not start another transaction. If an attempt is made to call a transaction from inside a running transaction, the server will throw error 1651 (nested transactions detected).
It is also disallowed to execute user transaction on some of C8's own system collections. This shouldn't be a problem for regular usage as system collections will not contain user data and there is no need to access them from within a user transaction.
Some operations are not allowed inside transactions in general:
- creation and deletion of databases
- creation and deletion of collections
- creation and deletion of indexes
If an attempt is made to carry out any of these operations during a transaction, C8 will abort the transaction with error code 1653 (disallowed operation inside transaction).
Finally, all collections that may be modified during a transaction must be declared beforehand, i.e. using the collections attribute of the object passed to the _executeTransaction function. If any attempt is made to carry out a data modification operation on a collection that was not declared in the collections attribute, the transaction will be aborted and C8 will throw error 1652 unregistered collection used in transaction.
It is legal to not declare read-only collections, but this should be avoided if possible to reduce the probability of deadlocks and non-repeatable reads.
Please refer to Locking and Isolation for more details.Top