1. Lore multi-user support
Lore can be used in multi-user (default) or single-user mode
(lore -s).
Lore can be compiled without locking or without logging for test purposes.
Lore API calls with are affected by multi-user,cc and logging/recovery support:
Connect (dbname, quitfn, muser);
Commit, Abort;
ChkPt;
Disconnect(cmt);
Lore Cmd line interface only:
Transactions can be multi-statement (default) or autocommit
(lore -ac).
Common data is stored:
Buffer mgr strategy (given): steal - no-force ->
Log/Recovery: Page based undo/redo log on single file (no media recovery).
3. CC approach
BufferMgr::Get first tries to acquire lock (S or X). If not
successful Get
returns error code which will be caught. At the moment the error will result
in aborted transaction (lore cmd line interface).
4. Logging
Each X locked page gets an undo log entry which is first written to the
buffer.
Redo log is written when releasing lock.
WAL is guaranteed by BufferMgr.
A DB flush and a db disconnect set log checkpoints.
Undo log logs:
Redo log logs:
File creation is not logged but left to GC at end (performed by workspace manager).
5. Recovery
dbrecover connects in single-user mode (allows overwrite),
removes OS semaphores, deletes mapped files for buffer and lock manager,
reinitialises database, resets log semaphores, and performs recovery (redo of
all tas starting at last checkpoint and then undoing all active tas). Finally,
GC is called and the log and buffer files are deleted.
6. Utilities and Tests
lshow [-i sec] dbname
logshow [-i sec] dbname
bufshow [-i sec] dbname
tester/test_ta
tester/test_recovery
7. CC/Recovery and Programming in Lore below API
Recovery should be handled transparently to the programmer above the
buffer manager level.
CC only requires that the correct lock mode is set (below LWObject and above buffer manager).
If you use LWObject:
8. Open issues
Client/Server: Use heavy server/light client approach
Better Deadlock detection.
Performance studies. May lead to some changes in physical layout....