Next: , Previous: DSR Cursors, Up: Data Store API Reference

8.6 Transactions

These functions must be implemented or stubbed by all data stores.

— Generic Function: elephant-data-store:execute-transaction store-controller txn-fn &rest rest &key &allow-other-keys

This is an interface to the backend's transaction function. The body should be executed in a dynamic environment that protects against non-local exist, provides acid properties for db operations within the body and properly binds any relevant parameters.

— Generic Function: elephant-data-store:controller-start-transaction store-controller &key &allow-other-keys

Start an elephant transaction

— Generic Function: elephant-data-store:controller-commit-transaction store-controller transaction &key &allow-other-keys

Commit an elephant transaction

— Generic Function: elephant-data-store:controller-abort-transaction store-controller transaction &key &allow-other-keys

Abort an elephant transaction

These are supporting functions and variables for implementing transactions.

— Variable: elephant-data-store:*current-transaction*

The transaction which is currently in effect.

— Function: elephant-data-store:make-transaction-record sc txn

Backends must use this to assign values to *current-transaction* binding

— Function: elephant-data-store:transaction-store txnrec

Get the store that owns the transaction from a transaction record

— Function: elephant-data-store:transaction-object txnrec

Get the backend-specific transaction object

;; Designer considerations: ;; - with-transaction passes *current-transaction* or the user parameter to execute-transaction ;; in the parent keyword argument. Backends allowing nested transactions can treat the transaction ;; as a parent, otherwise they can reuse the current transaction by ignoring it (inheriting the dynamic ;; value of *current-transaction*) or rebinding the dynamic context (whatever makes coding easier). ;; - ensure-transaction uses *current-transaction* to determine if there is a current transaction ;; in progress (not null). If so, it jumps to the body directly. Otherwise it executes the body in a ;; new transaction by calling ... ;; - execute-transaction contract: ;; - Backends must dynamically bind *current-transaction* to a meaningful identifier for the ;; transaction in progress and execute the provided closure in that context ;; - All non-local exists result in an abort; only regular return values result in a commit ;; - If a transaction is aborted due to a deadlock or read conflict, execute-transaction should ;; automatically retry with an appropriate default amount ;; - execute-transaction can take any number of backend-defined keywords, although designers should ;; make sure there are no semantic conflicts if there is a name overlap with existing backends ;; - A typical design approach is to make sure that the most primitive interfaces to the backend ;; database look at *current-transaction* to determine whether a transaction is active. Users code can also ;; access this parameter to check whether a transaction is active.