target\binThe
\target\bindirectory under your eXtremeDB installation root contains Java archivesextremedb.jarandextremedb_jdbc.jar, apythonsubdirectory, and a number of binary libraries described below. The Java archive files are required only for Java applications and JDBC applications. The Python subdirectory contains shared object libraries andexdb.py, which are required for Python applications.Python Subdirectory
The
\target\bin\pythondirectory contains the eXtremeDB Python implementation source fileexdb.pyand the following Windows Dynamic Link Library files. (As for native C libraries, both debug (with suffix_debug) and release mode versions are provided. Only the release mode filenames are listed below.)eXtremeDB_im_mursiw.pydeXtremeDB_im_mursiw_shm.pydThe MURSIW transaction manager for shared memory.eXtremeDB_im_mvcc.pydeXtremeDB_im_mvcc_shm.pydThe MVCC transaction manager for shared memory.Native C Libraries
The libraries provided for all eXtremeDB packages are described below. (Please refer to the following link for descriptions of additional libraries to support extension module features.)
The native C libraries (upon which the C++, Python, Java, and .NET Framework wrappers depend) are described in the sections below. Each library is provided in two forms:
- Debug — used during development to aid in finding application-level errors; contains several levels of checks for possible erroneous argument values and other error conditions that should be caught and resolved before application deployment. These are easily recognized by the
_debugsuffix in the filename.- Release — used when the development cycle is completed or when performance comparisons are desired; because most of the checks built into the debug version are removed, this version of the libraries performs significantly faster.
(Only release mode filenames are shown in the sections below.)
The Windows eXtremeDB runtime can be linked to applications in two ways:
- Statically as a set of static libraries (with extension
.lib)- Dynamically using a set of dynamic libraries (with extension
.dll)Whereas C and C++ applications will normally statically link the appropriate eXtremeDB libraries, Python, Java, and .NET Framework applications load DLL versions of the necessary libraries at runtime. Use of the dynamically linked runtime provides advantages:
- The ability to choose the exact runtime features at application start time, rather than at link time.
- The ability to create and call User-Defined Functions from the SQL engine, as they are created as plugin modules.
Static Libraries
The sections below describe the static libraries that comprise the eXtremeDB runtime. For a description of the dynamic libraries, see pages eXtremeDB Windows Dynamic Link Libraries and eXtremeDB Extension Module Windows Dynamic Link Libraries.
Required Libraries
The following tables list the essential libraries that implement the eXtremeDB functionality. Platform-dependent functionality is implemented in the set of libraries called the System Access Layer (SAL). At least one library from each of the categories below must be linked to C and C++ applications together with the supporting SAL libraries.
The SAL libraries in the following table implement the indicated functionality for all supported platforms:
mcosalatomic.libAtomic operations.mcosallatches.libLatches implementations.mcosaltimer.libLow-resolution and high-resolution timer implementations.mconet.libSystem network layer.mcosalmem.libSystem memory management.mcosalsmp.libSystem mutex, semaphores, threading, and other multi-thread/process related code.mcosaldload.libSystem dynamic loader.mcosalhollow.libStub functions for in-memory database single-threaded applications only.Core Runtime
Of the following libraries,
mcolib.libis required for basic eXtremeDB functions, and eithermcovtmem.libormcovtdsk.libis required depending on whether a persistent database is used:mcolib.libMain database functions.mcovtmem.libVirtual Table management for all-in-memory databases.mcovtdsk.libVirtual Table management for persistent and hybrid databases.Memory Device Manager
Depending on the type of database memory device being used, one of the following libraries is required:
mcomconv.libConventional memory device.mcomalloc.libConventional memory device with internal memory allocation by the eXtremeDB runtime.mcomw32.libShared memory device.Transaction Manager
Depending on the choice of Transaction Manager, one of the following libraries is required:
mcotmursiw.libMURSIW (MUlti-Read-Single-Write) transaction manager.mcotmvcc.libMVCC (Multi Version Concurrency Control) transaction manager.mcotexcl.libEXCLusive transaction manager.Concurrency Management
One of the following libraries is required to manage synchronization of database access from multiple threads or processes.
(Note that for minimalistic single-threaded in-memory database applications, a “hollow” synchronization stub is provided in library
mcosalhollow.lib. It has no synchronization code, so it is the fastest implementation—but it is valid for single-threaded applications only. If the application links withmcosalhollow.lib, then no synchronization library is necessary.)mcosw32.libNative Windows synchronization with “atomic operations” to avoid unnecessary kernel calls.mcosw32n.libNative Windows synchronization without “atomic operations”.Persistent Database Support
All C and C++ applications using the Persistent Storage APIs must link with
mcovtdsk.libinstead ofmcovtmem.libfor "virtual table" control. In addition, the following file system library is required:mcofw32.libWindows file system support.Utility Functions
Miscellaneous functionality used in eXtremeDB internals is provided in the following libraries. Depending on whether the standard C runtime libraries are used, one of these is required:
mcouwrt.libUtilities using the C runtime.mcounrt.libUtilities without the C runtime.Optional Libraries
The following sections describe optional libraries that are required only for the specified eXtremeDB features:
Dynamic Module Loader [Optional]
The following library provides the capability to dynamically load parts of the eXtremeDB core on request:
mcoloader.libProvides themco_core_load()API to dynamically load parts of the eXtremeDB core on request.Sequence Data Type Support [Optional]
These libraries provide basic
sequencedata type operations such as reading and insertingsequencedata. All applications that use thesequencedata type must link with one of the following libraries:mcoseq.libSequencedata type API support.mcoseqrle.libSequencedata type with RLE compression API support.Analytics Function Library Support [Optional]
If, in addition to basic sequence operations, mathematics and statistical functions that operate on sequences are required, applications must link with one of the following libraries:
mcoseqmath.libMathematical and statistical functions operating onsequences.mcoseqrlemath.libMathematical and statistical functions operating onsequenceswith RLE compression.Active Replication Fabric Support [Optional]
eXtremeDB Active Replication Fabric packages provide the following libraries. All applications that use ARF (IoT) APIs must link with both:
mcoiotcomm.libIoT communication library.mcoiotrepl.libIoT replication.Transaction Logging APIs [Optional]
The eXtremeDB Transaction Logging APIs are implemented in the following library. All applications that use the Transaction Logging API must link with:
mcolog.libTransaction Logging API.In addition, all applications that use the Transaction Logging APIs must link with a File System Wrapper library (see the Persistent Database Support section above).
Backup [Optional]
The following library is provided for applications using the incremental backup feature to backup and restore databases on persistent media:
mcobackup.libIncremental backup and restore for in-memory and persistent databases.Serialization [Optional]
The following library is provided for applications using the
save/loadfeatures to store and retrieve database or class snapshots on persistent media. (Note that this functionality does not require file system wrappers. Thesave/loadfeatures use an abstract stream (implemented by the application) to transfer data to the operating system.)Serialization capability is implemented in the following library:
mcoseri.libSerialization (save and load) for all-in-memory databases.Uniform Data Access (UDA) [Optional]
For applications that use the Uniform Data Access functions, the following library is required:
mcouda.libRequired if UDA APIs are used.Debug Error and Tracing Diagnostics [Optional]
The eXtremeDB tracing framework allows applications to output trace and debugging information to a log file. If desired, the following library can be included:
mcotrace.libRequired if the tracing framework is used.Database Calculator [Optional]
The following library is required for applications that use the database calculator:
mcodbcalc.libDatabase Calculator implementation.Cryptography [Optional]
The Database Encryption feature requires one of the following libraries:
mcocryptaes.libAES encryption algorithm.mcocryptstub.libEmpty encryption APIs for custom implementation.