ZOIS *
Search *
Table of Contents *
Open OLTP News
Encina was originally developed as an experimental
Transaction Processing Monitor (TPM) at Carnegie Mellon University, the commercial sponsors being
IBM. Camelot, as it was known, used Mach Operating System Remote Procedure Calls
(RPC)s which it made Transactional. Camelot built on earlier work
known as the TABS project and even earlier academic projects such as
Argus [Liskov]. Camelot had its own programming language, which was somewhat
object orientated and contained the notion of persistence. Encina, by
now built upon DCE, went commercial with its Academic mentors,
chiefly Alfred Spector as Transarc in 1991. Transarc eventually became
a wholly owned subsidiary of IBM and IBM renamed it "IBM
Pittsburgh". In 2002 IBM shut this down and in time the Transarc
Domain name was eventually transfered to an adult-content
web-site. Encina itself continued as part of the TXSeries offering
until version 6 of that product when the API was withdrawn. Transarc's
DCE support (required by Encina) continued under the IBM banner
until 2007, when it was formally withdrawn. Encina support continued,
but only to existing customers with the appropriate contract. It was
completely out-of-support by 2009.
General Description
Encina had a concept of Cell which is not to be confused with a DCE cell, in which the Encina cell is encompassed. The Encina Cell is the largest unit configurable via the DCE cell which Encina knows about (without resorting to gateways). In this Encina is like Tuxedo, and its Bulletin Board, except Encina Cells are arguably more scalable.
Encina was a client/server system, with clients making requests of servers. They do this by using the DCE RPC (Remote Procedure Call) mechanism which Encina extends with Transactions. RPCs require a vote in two phase commit policy too.
Encina is multi-threaded. A single Encina server process, called a
Processing Agent (PA) can process several client requests at
once. The programmer has to be dextrous in the use of multi-threaded
programming and the special locks known as a "MUTEX" which allow several
threads access to a single memory model. In this respect Encina has
several constructs which make this task easier (for example,
cofor). Several single threaded PAs can of course be
started at once and are managed by the Encina system in much the same
way as Tuxedo and Top End.
More Information
Information on Encina use was to be found on IBM's somewhat spartan
TXSeries web-site but has now gone.
There is also historical and educational interest
in the book on Camelot and Avelon [Eppinger, Mummert & Spector], one of
a number of books on OLTP.
Example Code for Encina
Remember the Source Code caveats.
Found in the client ...
inFunction ("my_prog");
mon_InitClient ("my_prog", "/.:/cellname");
transaction {
debit_credit (delta, remote_account);
exec sql select amount from dosh_on_local_database
into :amount
where
account = :local_account;
if (amount - delta < 0)
abort ("cant go overdrawn!");
exec sql update dosh_on_local_database
set amount = amount - :delta
where
account = :local_account and
amount = :amount;
} onAbort {
printf ("Sorry, couldn't do it $s\n", abortReason ());
} /* onAbort */
mon_ExitClient (0);
A language Transarc call Transactional C is used which is actually a
collection of 'C' macros. The Transactions are bracketed with special
keywords transaction, onAbort and
onCommit (not shown). We can prematurely mark a
Transaction as a failure using abort, which is not to be
confused with the UNIX function call of the same name. In
the example we don't want to go overdrawn and this is how the
Transaction is marked a failure by the user. The remote work is done by
a function debit_credit, the function, although it looks
local is actually an Remote Procedure Call (RPC) whose interface is
defined by code in an Interface Definition Language (IDL). Encina is
based on DCE which provides the RPCs and the IDL. Encina's RPC and
IDL are, however, given some extensions to make them Transactional. As
a Transactional RPC debit_credit also has a
vote in the two phase commit. Should the transaction be marked as a
failure then the transaction here in the client will fail
too and the entire Transaction (client and server) will be rolled
back. The update will not be made. The
onAbort is mandatory to allow reporting of failures.
The client, which as we can see has the Transaction control calls the
debit_credit Transactional RPC ...
void debit_credit (idl_char delta[],
idl_char remote_account[])
{
inFunction ("debit_credit");
exec sql select amount from dosh_on_remote_database
into :amount
where
account = :remote_account;
if (amount + buf->delta) < 0)
abort ("can't go overdrawn!");
exec sql update dosh_on_remote_database
set amount = amount + :delta
where
account = :remote_account and
amount = :amount;
} /* debit_credit */
As far as the SQL is concerned the server is much like the client.
Note how the call abort is used to mark a Transaction as
being failed (the default we assume is success). The function
abortReason will actually return an indication of this,
although there are more complicated and efficient ways of doing this.
Encina's Name
Although there appears to be no solid documentation it is understood that "Encina" stands roughly for "Enterprise Network Computing in a New Era". Yes, we realise that if this were entirely correct then it should be ENCINE, but what's an 'A' or an 'E' when you are inventing these things anyway.
It seems that "Encina" means "Oak" in Castilian Spanish and thus
results in a number of places and family names (see questions on ZOIS's name
for more examples of this type of inadvertent name overloading).
$Date: 2009/10/20 12:32:19 $