Erlang & databases

Hakan Mattsson hakan@REDACTED
Thu Jun 17 14:10:23 CEST 1999

On Thu, 17 Jun 1999, Roberto Moreda wrote:

moreda>Date: Thu, 17 Jun 1999 10:37:10 +0200
moreda>From: Roberto Moreda <moreda@REDACTED>
moreda>To: Erlang Questions <erlang-questions@REDACTED>
moreda>Subject: Erlang & databases
moreda>I'm looking for the possibility to mix Java (only as front end) and Erlang in a
moreda>project of a (mini) bussines management system. 
moreda>Where can I found info related to Erlang access to commercial databases
moreda>trough any standard (OBDC)?

The ODBC binding for Erlang is not released yet. But you can read this
for the time being:

moreda>Is mnesya suitable for this kind of app? How much?

Yes, if it is possible to put the most database intense parts of your
application in Erlang. Mnesia is a DBMS primarily intended to be used
by applications written in Erlang. Normally, Mnesia and its applications
runs in the same address space (in the same OS process). When you have
a front end written in Java you may end up with a severe communication
overhead. This depends of course a lot of your (application level)
interface between Java and Erlang.

Mnesia Session is a foreign language interface for Mnesia and you may
read about it at:

The generic interface of Mnesia Session is rather low level and is
mostly intended for database administration applications. You should
put some efforts to design a customized high level interface between
your Java front end and your Erlang back end.

A little example:

    divorce(Name) ->
       F = fun() ->
    	   case mnesia:read(Name) of
    	      [] ->
    	      Pers ->
    		 Partner = mnesia:read(Pers#person.married_to),
    		 mnesia:write(Pers#person{married_to = undefined}),
    		 mnesia:write(Partner#person{married_to = undefined})

Assume that your Java front end needs to perform some access of person
records stored in a Mnesia database. In the divorce/1 example it is 2
read accesses and 2 write accesses.

When using the generic interface of Mnesia Session you would easily
end up with a RPC between Java and Erlang for each of these 4
accesses. An obvious better design which harmonizes better with
the application logic, is to write an own IDL spec with divorce/1
as sole function (one single RPC access).


More information about the erlang-questions mailing list