Re: Using TCL instead of CORBA

From: Andrew Piskorski (atp_at_piskorski.com)
Date: 05/04/04 

Date: 4 May 2004 06:53:12 -0700

"Gerald W. Lester" <Gerald.Lester@cox.net> wrote in message news:<Qttjc.2142$f_5.1076@lakeread01>...
> Ravi wrote:
> > Connection Pooling:

> > Instead I want to have a pool of database connections which I could
> > make use of whenever required.
> >
> > Is this kind of approach is possible using ORATCL, if so can anybody

> Yes oratcl supports this in serveral ways.
>
> When you log into Oracle via oratcl (oralogon) you get a login handle, you
> can have multiple of these.
>
> You can also have several "cursors" active per logon (oraopen).

AOLserver supports database connection pooling out of the box with no
additional effort on your part whatsoever. Sounds like Oratcl gives
you all the pieces you need to build connection pooling yourself
without too much difficulty. Nstcl, which uses Oratcl to emulate the
AOLserver database API, probably already provides connection pooling
out of the box as well, but I'm not sure about that.

You probably do NOT want to use Oracle's MTS ("Multi Threaded Server")
stuff to do connection pooling on the Oracle server side.

MTS was known to have serious stability problems in certain versions
of Oracle 9i, and although those have probably been fixed by now, MTS
is more complicated, and most people using Oracle, even most people
who need connection pooling, do NOT use MTS. So, most likely, the
simplest and safest route for you is to not use MTS either.

Basically, MTS was intended for client-server apps where hundreds or
thousands of desktop applications all over a company would be
connecting to a single Oracle server. For that scenario, you need
something like MTS.

If instead, you have a single server-side application which needs to
make many connections to Oracle, and re-use them rapidly without the
overhead of starting up and shutting down a connection each time, you
are probably better off putting the connection pooling into the
application, and using traditional one-process-per-client connections
on the Oracle server. This has the side benefit that if you ever want
to support a different RDBMS (PostgrSQL, Interbase/Firebird, MS SQL
Server, DBM2, Sybase, etc.), you're connection pooling design will
work exactly the same there as well.

Relevant Pages