Next: , Previous: Transaction Details, Up: User Guide


4.12 Multi-repository Operation

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.