DataBlade Module Development Overview

DataBlade Module Development Overview
Chapter 1: DataBlade Module Concepts

Home Contents Index Master Index New Book

DataBlade Modules and Informix Dynamic Server

This section discusses the overall architecture of Informix Dynamic Server with Universal Data Option, how DataBlade modules affect database server processes, and the application programming interfaces you can use in your DataBlade modules and client applications.

Figure 1-1 illustrates the following components of Informix Dynamic Server architecture:

DataBlade modules, which extend the capabilities of the database server
The DataBlade application programming interface (API), which allows DataBlade modules access to data stored in an Informix Dynamic Server database
The database server, which includes virtual processors that Informix Dynamic Server uses to schedule tasks and the shared memory that these virtual processors use
Client-side APIs, which enable you to write client applications that access data stored in an Informix Dynamic Server database
DataBlade module ActiveX value objects, which enable you to provide client-side interfaces to extended data types and their support routines
Client applications, which allow the user access to DataBlade module functions and data stored in an Informix Dynamic Server database

Figure 1-1
Informix Dynamic Server Architecture

The close integration of DataBlade modules with the database server means that the database server treats new, extended data types in exactly the same way that it treats its own built-in data types.

Informix Dynamic Server Internal Architecture

If you want to add user-defined routines to Informix Dynamic Server, you must understand the internal architecture of the database server and how DataBlade module routines can affect the overall performance of the database system. Two critical aspects of Informix Dynamic Server internal architecture are:

virtual processors
memory management

DataBlade Modules and Virtual Processors

The internal architecture of Informix Dynamic Server contains virtual processors. Virtual processors are operating system tasks that carry out requests.

Virtual processors are separated into virtual processor classes. Each virtual processor class handles a different type of task, such as executing queries and routines, fetching data from disk, and administering network connections.

The main virtual processor, the CPU VP, acts as a router. The CPU VP receives client requests, such as SQL queries, and sends them to an appropriate virtual processor; then the CPU VP begins carrying out the next request. Distributing tasks among virtual processors improves performance.

Most SQL queries are data-intensive and require I/O operations to fetch data from the disk. The CPU VP routes SQL queries requiring I/O to the appropriate I/O virtual processor.

In contrast to SQL queries, user-defined routines from DataBlade modules can be function-intensive and require processing by the CPU VP. While the CPU VP is processing the user-defined routine it cannot process any other requests. Therefore, DataBlade module routines can have a significant effect on the performance of the whole database system.

The alternative to running DataBlade module routines in the CPU VP is to assign them to user-defined virtual processor classes. User-defined virtual processors are created by the database administrator and run only the user-defined routines that are assigned to them. When the CPU VP receives a user-defined routine that is assigned to a user-defined VP, the CPU VP routes the routine to the appropriate user-defined VP. If performance is a critical issue for your database system, you should use user-defined VPs for your user-defined routines.

When you create a user-defined routine, you can specify a user-defined VP class in which they run; a user-defined VP must exist for that class before you can run the routine.

For more information about virtual processors, see the DataBlade Developers Kit User's Guide and the INFORMIX-Universal Server Administrator's Guide.

DataBlade Module Memory Allocation

Another important aspect of Informix Dynamic Server internal architecture is that virtual processors communicate with one another through shared memory. Therefore, when you write code for user-defined routines, you cannot use standard memory allocation functions. To manage memory for DataBlade modules, you must use mi_alloc and other memory management functions provided by the DataBlade API.

See the DataBlade API Programmer's Manual for complete information.

Application Programming Interfaces

This section briefly describes the following application programming interfaces that you can use when writing DataBlade module code and client applications:

DataBlade API
INFORMIX-Object Interface for C++
INFORMIX-GLS
INFORMIX-ESQL/C

You can use the DataBlade API, INFORMIX-GLS, and a subset of ESQL/C and the Object Interface for C++ in DataBlade module code.

DataBlade API

The DataBlade API is the primary API for Informix Dynamic Server. The DataBlade API provides routines that enable you to manage database connections, send SQL command strings, process query results, manage database server events and errors, create database server routines, manage database server memory, and so on. You can use DataBlade API routines in your DataBlade module code.

For more information about the DataBlade API, see the DataBlade API Programmer's Manual.

INFORMIX-Object Interface for C++

The Object Interface for C++ enables you to create C++ objects that encapsulate Informix Dynamic Server data types. Using this interface, you can write C++ applications to issue queries and retrieve results from Informix Dynamic Server databases.

For information on how you can use the Object Interface for C++ in your DataBlade module code, see "DataBlade Module Programming Language Options". For more information about the Object Interface for C++, see the INFORMIX-Object Interface for C++ Programmer's Guide.

INFORMIX-GLS

INFORMIX-GLS enables you to write new programs-or change existing programs-to handle different international languages, cultural conventions (such as dates, time, and money), and code sets. You can use INFORMIX-GLS in your DataBlade module code to process character strings and date and money values independent of locale. Data types that contain string, date, or money values rely on INFORMIX-GLS routines to convert the information that the database user expects. Links to the INFORMIX-GLS library are for the most part generated automatically by BladeSmith.

For more information about INFORMIX-GLS, see the INFORMIX-GLS Programmer's Manual and the Guide to GLS Functionality.

INFORMIX-ESQL/C

INFORMIX-ESQL/C allows client application programmers to embed SQL statements in a C program.

You can use the INFORMIX-ESQL/C library functions provided by the DataBlade API in your DataBlade module code. These library functions work with the GLS API library to provide a full set of string processing and data conversion utilities. Links to the INFORMIX-ESQL/C library are generated automatically by BladeSmith.

For more information about INFORMIX-ESQL/C, see the INFORMIX-ESQL/C Programmer's Manual and its supplements.

DataBlade Module Development Overview, version 3.6
Copyright © 1998, Informix Software, Inc. All rights reserved.