Search:
|
Access:
» Developing a custom database - LhimkDB. Part 2: developing the data access layerRelated categories: C/C++ | Embedded databases Pawel MarciniakViewed: 4633 | Article date: 2006-01-18 16:05:36 LhimkDB is developed in a language of my devising called Lhimk. It is so similar to C/C++ that there is little point in learning it separately, let alone writing tutorials for it. In this article we will look at the lowest database layer – a data access layer called UDB (Unordered Database). UDB is of course part of LhimkDB, but both the tasks it performs and its implementation are flexible enough to warrant using UDB as an independent library providing persistent data storage.
Pawel has been involved with software development for 20 years now, using mainly C/C++. For the past 3 years he has been working on the Lhimk dynamic compilation framework. Contact with the author: pawel@software.com.pl
My previous article was the first in a series on developing a custom database system. To recap briefly, we're developing a key-value embedded database. In the previous article I argued in favour of developing a new database system and presented a project design along with the requirements and logical model. Just to remind you, Figure 1 presents an overview of the LhimkDB database system. In this article we will look at the lowest database layer - a data access layer called UDB (Unordered Database). UDB is of course part of LhimkDB, but both the tasks it performs and its implementation are flexible enough to warrant using UDB as an independent library providing persistent data storage.
Figure 1. Overview of LhimkDB architecture
LhimkDB is developed in a language of my devising called Lhimk. It is so similar to C/C++ that there is little point in learning it separately, let alone writing tutorials for it. Any language features found in Lhimk and not found in C/C++ are described in the inset Lhimk or within the article itself. Anyone who doesn't fancy using Lhimk (which I can well understand) can very easily rewrite all Lhimk code in C++. Lhimk code can also be linked to from within C/C++ code. Design goalsTo start with, let's formulate our expectations of UDB. The basic idea behind UDB is that of a more flexible heap memory model, with added persistence and transaction support. We'll start by declaring an interface, or the set of routines exported by UDB. Here are the necessary methods:
And that's basically the whole API. The char[[]] type is equivalent to (char* buf, uint len) - a resizable array with a specified initial size. This array declaration syntax is one of the few constructs specific to Lhimk and not found in C/C++. (Note that the peculiar-looking notation char fun()[[]] simply means that fun returns char[[]] and is actually valid C syntax). Transaction support means that we're allowing one writer thread and many reader threads, with the readers only seeing data that has been added to the database and committed with a call to commitTransaction(). If a thread requests data from the same PID twice while that PID is being written, it should get back the same data for both calls, meaning that only changes committed prior to the start of the read operation are visible to the reader. It is also necessary for the database to automatically recover consistency after a system failure, so that once it is up and running again it will only contain values entered by committed transactions. In practice this means that any transactions interrupted by a system failure without being committed should be rolled back. Finally, the database system should stipulate no limitations on database size in memory (up to the system memory limit), database size on disk (up to the maximum permissible file size) or transaction size. Listing 1. Minimalist implementation of the MFile class
|
|
Copyright C 2006 by Software Developer's Journal. All rights reserved.






SDJ Users:
Shopping Cart









