TimesTen In-Memory Database
for Extreme Performance

Direct And To The Point

Sam Drake

In my previous post I explained how the TimesTen In-Memory
Database is a very fast relational database. Like any relational database, TimesTen executes standard SQL via
standard APIs Because of TimesTen’s
“In-Memory” architecture, TimesTen can often use fewer CPU cycles than
competing technologies to achieve the same result … yielding very fast response

In addition to its use of RAM, TimesTen provides another
feature which helps it to provide very fast performance.

Relational databases, including TimesTen, let applications
running on many machines access the database. Applications make use of a client library or driver which provides the
database API. When the application calls
that API – to execute SQL or fetch a row, for example – the client library
formats the request from the application into messages, which it then transmits
to the database server. Typically TCP/IP
is used for communication.

On the database server, a process reads those messages from
the network and processes them…accessing or modifying data in the
database. Any results from the operation
are then, in turn, packaged up into messages and sent back to the client from
the database server.

This “client/server” design makes a lot of sense, and nearly
all databases – including TimesTen – support it. However, TimesTen supports another
alternative as well.

Direct Mode

TimesTen actually provides two different sets of libraries/drivers
that applications can use. Both sets
provide the same APIs – JDBC, ODBC, OCI, Pro*C. One set, the “client/server drivers”, work as explained above. The others, called “direct mode” drivers,
work in a more streamlined manner.

The TimesTen database engine is included in its direct-mode
drivers. When an application calls a
direct mode driver to execute SQL or fetch rows the driver doesn’t package that
request into messages. Instead, the
driver in turn directly calls the TimesTen database engine, which executes the
request directly. This is done without
the overhead of packaging requests and responses into messages, and without the
overhead of transmitting those messages on a network. In fact, since the database engine runs in
the customer’s application process, there isn’t even any context switch or IPC
(inter-process communication) overhead!

By using direct mode drivers instead of client/server
drivers, applications can achieve dramatic performance results. SQL can easily be executed in microseconds
(millionths of a second) instead of the typical milliseconds or more. When combined with the fast performance
provided by TimesTen’s in-memory architecture, direct mode applications can
achieve levels of performance that are hard to beat.


Since both direct mode and client/server mode drivers
provide the same APIs and capabilities, applications don’t need to be modified
to use direct mode. Both modes can be
used simultaneously, so some very response time critical applications might use
direct mode while other, less critical applications use client/server.

When applications run on the same machine that contains the
TimesTen database, they can use either TimesTen’s client/server or direct mode
drivers. If the application runs on a
different machine than TimesTen then the client/server drivers must be

Even in client/server mode, TimesTen provides very fast
performance. But by eliminating the
overhead of network round-trips and context switches entirely, direct mode can
provide applications with the fastest possible access to data, while still
using standard SQL, PL/SQL, and APIs.


Using direct or client/server database connections from
JDBC: http://docs.oracle.com/cd/E13085_01/doc/timesten.1121/e13068/writing_app.htm#BABJIJHI

Using direct or client/server database connections from “C”
applications: http://docs.oracle.com/cd/E13085_01/doc/timesten.1121/e13066/writing_app.htm#CEGGJGDG

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.