Next: Multiple Processes and Distributed Applications, Previous: Transaction Details, Up: User Guide
Elephant maintains a small hashtable that maps “database
specifications” into actual store-controller
objects.
The basic strategy is that the “database specification” object is stored in every persistent object and collection so that the repository can be found. In this way, objects that reside in different repositories can coexist within the LISP object space, allowing data migration or multiple user stores.
All persistent instances store their oid and a store-controller
reference in internal slots. Slot access and other protocols use
this to provide access. This executes an auto-transaction or joins
a surrounding transaction if the transaction-record
in
*current-transaction*
matches the store.
When operating with multiple stores and nested transactions there are
some subtle issues to work around: how to avoid writing one store with
a transaction created in the context of another. A nested or ensured
transaction is only indicated in the call to
execute-transaction
if the store controllers match, otherwise a
new transaction for that store is created.