The interfaces of the Mnesia_Session application are
defined in IDL (Interface Definition Language). The IDL module
mnesia
consists of two interfaces:
When a Mnesia_Session client needs to access the Mnesia
DBMS it locates a connector
on some Erlang node and
starts a session
there by applying the connect
function on the connector.
Once the client has started a session
it may use it to
perform various Mnesia functions. The functions are performed
locally on the Erlang node where the session
resides. Most of Mnesia's functions have location transparent
behavior, but some of them (e.g. start/0
) do not.
The Mnesia_Session interfaces makes it possible to
access the administration and dirty functionality of
Mnesia. To use transactions and/or Mnemosyne
queries it is up to the user to define the needed interface in
IDL. Implementing a user specified interface allows an
opportunity to skip the general handling of erlang::term
,
which can sometimes be troublesome when using foreign languages,
for both mnesia_session
and the mnesia_corba_session
.
See the IDL specification for functions which are available. The specification resembles the Mnesia API as much as possible. Please, read the Mnesia documentation set regarding the semantics used in the interface.
All the functions in the session ( and corba_session) API return
Status
which indicates if the operation was successful or
not. Most of the functions have an out parameter with a
string reason
describing the error, if one occurs.
![]() |
The return value |
The IDL specification of Mnesia_Session has two
alternatives when compiling. These can be found in the
mnesia_session/include
directory:
The mnesia_session.idl
file must be compiled with
IC
(OTP's own IDL compiler). The generated stub files
use the proprietary distribution protocol of Erlang
(erl_interface/jinterface) to carry out the communication between clients
and servers of connectors and sessions. On the server side
Mnesia_Session is implemented in Erlang using
Mnesia
's public API. On the client side Erlang, Java or C may
be used.
The mnesia_corba_session.idl
file may be compiled with
any Corba compliant IDL compiler (e.g. Orbix,
JacORB, TelORB, IC, ...) . The generated stub files uses IIOP (a
protocol standardized by OMG) to carry out the communication
between clients and servers of connectors and sessions. On the
server side Mnesia_Session is implemented in Erlang using
Mnesia's public API. On the client side a wide range of
programming languages are available: Java, Smalltalk, C++,
Erlang etc.
When the Mnesia_Session application is started, an
Erlang process with the registered name
mnesia_connector is created. The following example
illustrates how a session
is started:
% erl 1> application:start(mnesia_session). ok 2> Name = mnesia_connector, mnesia_connector 3> Connector = erlang:whereis(Name). <0.34.0> 4> Session = mnesia_connector:connect(Connector). <0.35.0> 5> ok = mnesia_connector:disconnect(Connector, Session). ok
![]() |
In the example given, both the client and server reside (in Erlang) on the same node. |
See the Orber and IC documentation about the language mapping between Erlang, Java, C and IDL.
If the Mnesia_Session application has been started with
the configuration parameter enable_corba
set to
true
, a mnesia_corba_connector object is also created (in
addition to the mandatory mnesia_connector process), and
registered in Orber. The following simplified example illustrates how
a corba_session
can be started:
% erl -mnesia_session enable_corba true 1> application:start(mnesia_session). 2> NS = corba:resolve_initial_references("NameService"). 3> NC = lname_component:set_id(lname_component:create(), "mnesia_corba_connector"). 4> Name = lname:insert_component(lname:create(), 1, NC). 5> Connector = 'CosNaming_NamingContext':resolve(NS, Name). 6> Session = mnesia_corba_connector:connect(Connector). 7> mnesia_corba_connector:disconnect(Connector, Session).
![]() |
In the example given, both the client and server reside (in Erlang) on the same node. |
More information about CORBA conventions and usage can be found in the Orber and IC documentation.
Since Orber uses Mnesia internally, some of the functions in the Mnesia API are not available via IIOP. Examples of such functions are:
See the IDL specification for the exact specification.
Some other functions are not supported due to the problem of
representing void objects of unknown types. The
dirty_[index_]match_object
functionality has been
replaced with the simpler function dirty_match_all
which
returns all records in a table.
These sessions are faster and more flexible variants than the CORBA session. The protocol implemented by the generated stubs is Erlang native external communication protocol, there is no ORB and IIOP engaged. Due to these facts the clients will run 10 to 20 times faster than in CORBA session case, depending on the amount of data stored and the mnesia record seeking times.
To be able to send records over the IIOP protocol, the records
must be defined as structures in an IDL specification, and
compiled with IC in order to enable registering of the
types in Orber's InterFace Repository (IFR). The records
are mapped to the type any
in Corba.
We recommend that all records are defined as IDL structures. This
also applies when the erl_interface
protocol is used (even though it may
work without it). By including the header files produced in the
code generation, several useful type definitions are made
available for the application.
The generic dirty access functions in the API of Mnesia_Session is merely included for the convenience of application developers and it may be tempting to organize the application code around these functions. The application interface between its clients and servers, should however be carefully designed according to the needs of the application, regardless of the Mnesia_Session interface.
Instead of sending records back and forth between the server and client nodes as in the generic get-/put-oriented interface of Mnesia_Session, it may (in many cases) be a better application design, to perform the application logic on the same (Erlang) node as the residing data. Besides the obvious performance advantage, it makes the applications more independent of future changes in the data model of the application.