Developers, please read the implementation notes on concurrency control and DietLore for more information.
1. What is the difference between Lore and DietLore?
Currently, Lore provides multi-user support on same
platform databases.
The multi-user support consists of
concurrency control and the ability to
lock databases in single-user mode and to enforce this lock. In order to
provide these functionalities, the implementation relies on operating system
semaphores, shared memory (implemented via mapped files) and shared memory
semaphores. Due to the various differences in operating systems, Lore
is currently only available for a limited number of platforms and will only
be ported to a new platform if necessary.
DietLore is a single-user version of Lore which does not provide any multi-user functionality. Concurrency control is not available and while DietLore assumes a single-user mode, it does not prohibit several connections to the same database. It is supposed to be available on a larger number of platforms than Lore and could easily be ported to new platforms.
Both implementations provide transactions and support logging and recovery. While Lore provides atomicity, consistency, isolation and durability for its transactions, DietLore only provides atomicity and durability.
At the moment a database generated with Lore cannot be used with DietLore or viceversa.
When connecting to a database, a system transaction will perform the startup operations before the first user transaction of this connection is automatically opened. A user then performs queries and updates on the database and can finish a transaction by either committing it (the transaction finishes successfully) or by aborting it (the transaction finishes unsuccessfully and all work performed during this transaction is undone). After finishing a transaction, the system automatically opens a new transaction. When the user disconnects, the currently open transaction is committed before the cleanup is performed during a system transaction.
The Lore API provides the following transaction related commands:
LoreConnection::Connect(...);
automatically starts the first user transaction.
LoreConnection::Commit();
allows the user to commit the currently open transaction and opens a new
transaction.
LoreConnection::Abort();
allows the user to abort the currently open transaction and opens a new
transaction.
LoreConnection::Disconnect(Boolean cmt);
disconnects from the database. If cmt is set to TRUE
(default), the currently open transaction is committed before the cleanup,
otherwise it is aborted.
The command line interface lore provides the following
two transaction modi:
commit; to
commit or by using abort; to abort it.
-ac a user can choose the auto-commit
mode in which lore automatically commits every statement
directly after its execution. In this mode, the user does not need to
perform any transaction commands, but cannot form transactions over
multiple statements.
The utilities dbcreate, dbload2,
and dbrecover
all run within a single transaction.
In order to be able to abort transactions and perform recovery, both Lore versions write page based undo and redo log records. The currently implemented logging and recovery allows to recover from application program, database engine and operating system failures, but it does not provide recovery from media failures.
In order to flush the data and log buffer to disk and therefore
avoid long recovery phases, the user can set a checkpoint with the API
function LoreConnection::ChkPt(); or the command line interface
command ChkPt;. Flushing the database or disconnecting from
a database automatically sets a checkpoint.
dbrecover
is provided for performing database recoveries. For both Lore versions it
reinitialises the database and performs recovery by redoing
all transactions starting at last checkpoint and then undoing all
active transactions. Finally,
the garbage collector is called and the log file is deleted.
The utility
logshow [-i sec] dbname
dumps the log file and log manager status. -i sec specifies the
interval for repeating the dump in seconds. If it is not specified the utility
dumps the current snapshot.
Users of the command line interface lore can connect in
single-user mode with the
command line flag -s. Note that this flag is only available
with Lore.
Example:
lore -s mydatabase connects in single-user mode.
Users of the API can set the brt_flag to FALSE
if they want to connect in single-user mode. The default is TRUE
and connects in multi-user mode.
Example:
LoreConnection lc.Connect("mydatabase", NULL, FALSE);
connects in single-user mode, while
LoreConnection lc.Connect("mydatabase", NULL);
connects in multi-user mode.
Some of the utilities request single-user mode.
4.2 Concurrency Control
Lore's concurrency control operates on the page level and
uses a strict two phase locking protocol with
a timeout based deadlock detection. The concurrency control mechanism allows
several readers on the same page, but if a transaction locks a page for
writing, no concurrent readers or writers are allowed on this page until
the transaction holding the lock finishes.
If a lock cannot be granted after
a certain amount of time, a deadlock is assumed and the waiting transaction is
aborted.
While the user performs queries and updates on the database,
the concurrency control automatically issues the correct locks for the
affected pages. The lock of a page which is read by one statement within a
transaction and then later written by another statement of the same transaction
is automatically upgraded if no other transactions possesses a read-lock on
this page. All locks are automatically release when finishing the transaction.
4.3 Logging & Recovery
See the general description.
4.4 Utilities
All the utilities which run within a transaction are automatically handled
by the concurrency control.
dbdestroy and dbrecover
both request a single-user connection. In both cases, a already existing
lock on the database can be overwritten. This is useful, if the database
crashed and the system keeps a lock for the failed connection, otherwise
be very careful when overwriting another database lock.
In addition to the above mentioned tasks, the
Lore version dbrecover utility also removes OS semaphores,
deletes mapped files for buffer and lock manager, resets log semaphores and
finally deletes the buffer file.
The following additional utilities are available for the full Lore version:
lshow [-i sec] dbname
[-i sec] specifies the repeat interval in seconds.
bufshow [-i sec] dbname
[-i sec] specifies the repeat interval in seconds.
Users of the command line interface lore and of the utilities
dbcreate and dbload2 can turn off logging with the
command line flag -nl. It is allowed to create and load a database
without logging and then use it with logging turned on.
Note that this flag is only available with DietLore.
Example:
lore -nl mydatabase connects without logging.
Users of the API can set the brt_flag to FALSE
if they want to turn off logging. The default is TRUE (logging
enabled).
Example:
LoreConnection lc.Connect("mydatabase", NULL, FALSE);
connects with logging disabled, while
LoreConnection lc.Connect("mydatabase", NULL);
connects with logging turned on.
5.2 Utilities
As already mentioned, the utilities
dbcreate and dbload2 allow to turn off logging.
The utilities lshow and bufshow are not available.
lore. Note that the example works for both the full Lore version
and the DietLore version for which the example is shown.
Bold is used to show the user's entries. Note that only the
relevant verbose output is shown.
lore -v mydatabase
DietLORE (Version 1.0)
======================
Compiled at: Dec 10 1997 - 22:09:31
Compiler: g++
Operating system: Solaris
Processor: Sparc
[Locking disabled, Logging enabled, single user, verbose]
Transaction 1 started.
Transaction 1 committed.
Transaction 2 started.
LORE: Global!x := "This is a test";
LORE: select x;
Query result:
(2,(1,10)) Answer
(2,(1,1)) x This is a test
LORE: commit;
Transaction 2 committed.
Transaction 3 started.
LORE: Global!x := 6;
LORE: select x;
Query result:
(2,(1,20)) Answer
(2,(1,11)) x 6
LORE: abort;
Undo LSN 46708 (page <1122222,2> of ta 3)
Undo LSN 42564 (page <1122222,1> of ta 3)
Undo LSN 38420 (page <1122226,0> of ta 3)
Undo LSN 34276 (page <1122226,1> of ta 3)
Transaction 3 aborted.
Transaction 4 started.
LORE: select x;
Query result:
(2,(1,15)) Answer
(2,(1,1)) x This is a test
LORE: exit;
Transaction 4 committed.
Transaction 5 started.
Checkpoint set.
Checkpoint set.
Transaction 5 committed.
6.2 Application Programming Interface (API)
The following is an example for doing the same queries and updates using the
API. Please note, that for improved presentation, the code which handles the
result of queries is left away.
#include "loreapi.h"
...
LoreOem *oem;
LoreConnection lc;
LR r;
r = lc.Connect("mydatabase", NULL);
r = lc.Submit("Global!x := \"This is a test\";", &oem);
r = lc.Submit("select x;", &oem);
r = lc.Commit();
r = lc.Submit("Global!x := 6;", &oem);
r = lc.Submit("select x;", &oem);
r = lc.Abort();
r = lc.Submit("select x;", &oem);
r = lc.Disconnect();