Notes for Linux ODBMS Developers

ObjectDatabase++ has be designed and developed for the needs of Microsoft’s COM+/DCOM environment and therefore we foresee some developers may wish to port their COMs over to a UNIX platform. Ekky Software has risen to the challenge by producing an embedded ODBMS for a number of UNIX flavors starting of with Linux. This page is to help these developers when trying to use ObjectDatabase++ on Linux, with some of the quirts of the OS.

First thing to note is that ObjectDatabase++ has been designed, developed and tested on the Linux kernel version 2.6.15. Previous versions should work as ObjectDatabase++ has minimal dependencies – implementing all but the bare basics, but it is Linux and there are no guarantees. The next thing you have to remember is that ObjectDatabase++ is a multi-threaded ODBMS – you have to compile your source with ‘g++ -pthread’, this is a must.

Dynamic Linking Libraries on Windows allows designers to hide or to export functions and classes, UNIX C++ does not, or I don’t yet know how to do this. I have seen some Linux C++ shared libraries that move all functions and classes into a standard namespace, then #define the names into the global name space. I have however decided that it would be easier for developers familiar with the Windows environment if I changed all the private functions to ES_pfXXX, (ie, Ekky Software private function). This should prevent any naming conflicts between ObjectDatabase++ internal functions and your own code.

ObjectDatabase++ uses the shared space provided by the Windows registry system to hold the ODBPP license information required by the library, this is a global space. On Linux systems, without a reliable shared space, ObjectDatabase++ contains its license information within a '/var/tmp/.ODBPP.ini' file. This file may change per user permissions and will therefore require you to install a file that all have permissions to at least read from.

As most people know, Linux can mount network drives into the local file system and I don't know how to prevent users from trying to interact two processes on different computers into the same data files. ObjectDatabase++ uses IPC through the local file system (*.odm) to enable its multi-process abilities and Kernel level semaphores for concurrency control, having two process on different machines would prevent the processes from communicating correctly and would most likely corrupt the data files. I am not sure how to stop this at this point in time so I am leaving it up to you to inform you clients of this Linux only problem.

The library is meant to run under the name "ODBPP.so.X.Y" where X is the major version number and Y is the minor version number. I am not sure how to distribute the link, so you have to run the command "ln -s ODBPP.so.X.Y.B ODBPP.so.X.Y", for example that would mean "ln -s ODBPP.so.3.2.1 ODBPP.so.3.2". This enables you to compile with the link and then your clients upgrades their copy of the shared library, they can do so without having to recompile or loose version information, for example you would now compile with "g++ -pipe -s ODBPP.so.3.2 yourfiles.cpp".
       The version information is important as minor versions are backwards compatible, so code written for version 3.0 will work with version 3.1 and so on, but code written with different major versions will not work with one another.

There are some problems with C style structures that use type 'long long int' and other basic data types over 4 bytes long, Windows forces them to be on a byte boundary of the same size where Linux forces them to be on the 32bit boundaries. This is somthing to look out for when creating systems using Linux C structs as ObjectDatabase++ uses Windows style structures.