.NET and connection pooling in Terminal Services

[Joni Moilanen]

Hi!
I'm designing an architecture that will be run on a 16-node Terminal
Services (Citrix) cluster. An Oracle 9i cluster contains the data and
ODP.NET will be the interface. Everything else is done on .NET 1.1. For this
particular apps there are about 20-100 simultaneous users, though design
will be stateless multi-tier, of course.

The problem is how to find the best trade-off between
performance/scalability. One important thing to consider is connection
pooling. I understand how it works in a "typical" multitier environment, but
this Terminal Services changes things a bit (or does it?).

Normally, no new pool is created if:
-Connection string is the same
-Process ID is the same (is it the same for multiple TS-clients on the same
physical server?)
-Application Domain is the same (see the question above)
-If there are no transactions outside database

If the application and all the dependent assemblies (client, BL and DAL) are
installed to the TS, will there be 16 connection pools (1 per TS-node) or
one pool/user thus no usable pooling?

If the pooling doesn't work in above situation, we may need to move the DAL
to a centralized server and use .NET Remoting. However, this I would like to
keep as the last resort.

That question about processes and application domains is the most important
ones at the moment, but all suggestions are welcome, too

Thanks,

 

[David Browne]

Hi!
I'm designing an architecture that will be run on a 16-node Terminal
Services (Citrix) cluster. An Oracle 9i cluster contains the data and
ODP.NET will be the interface. Everything else is done on .NET 1.1. For this
particular apps there are about 20-100 simultaneous users, though design
will be stateless multi-tier, of course.
. . .

If the pooling doesn't work in above situation, we may need to move the DAL
to a centralized server and use .NET Remoting. However, this I would like to
keep as the last resort.

Your connections won't pool unliess your DAL is remoted to an app server.

BUT . . .

20-100 simultaneous connections is _nothing_ for your Oracle cluster. You
will not improve performance by pooling your clients. Connection pooling is
required to reduce the velocity of connections opening and closing in
stateless application servers, and to handle truly large numbers of
simultaneous users (also in stateless application servers). For a
client-server app, you don't need connection pooling. Moreover connection
pooling complicates authentication and blocks use of some really handy
Oracle features.

Look at it this way: all that money you're paying for Citrix, what you're
buying is the ability to deliver client/server computing out to far-flung
clients. Make your app small, fast, slick, connected and stateful. Or,
ditch Citrix/TS and write a ASP.NET application.

If you deploy your DAL on an application server you might as well ditch
Citrix/TS and have your clients download your application to their PC's
anyway.

Remember winforms apps rock. Users love them, developers love them and
Oracle loves them. Just don't over-complicate the solution. You really
don't want to buy all the infrastructure, deployment and management cost of
introducting an app server if you don't need to.

David

 

[bruce barker]

each TS instanace of your app will be a seperate appdomain (and pid), so
each instance will have its own pool. you can turn pooling off, make the
pool small, or remote to a DAL hosted on the TS server.


-- bruce (sqlwork.com)

 

[Joni Moilanen]

each TS instanace of your app will be a seperate appdomain (and pid), so
each instance will have its own pool. you can turn pooling off, make the
pool small, or remote to a DAL hosted on the TS server.
-- bruce (sqlwork.com)

Thanks for makig things clearer

-Jemm

 

[Joni Moilanen]

Your connections won't pool unliess your DAL is remoted to an app server.
BUT . . .
20-100 simultaneous connections is _nothing_ for your Oracle cluster. You
will not improve performance by pooling your clients. Connection pooling

is

Thanks for the reply.
There are also other database apps that take up connections. They claim they
can handle 200 hundred connections at max, but it sounds suspiciously low to
me.

If you deploy your DAL on an application server you might as well ditch
Citrix/TS and have your clients download your application to their PC's
anyway.

Well, probably a separate application server is an overkill, but what if the
Remoting-separated DAL was installed on each node of the cluster that the
different processes/appdomains shared?

So, WinForm clients would connect to BL-assemblies that connect through the
remoting to the DAL on the same node.
I think that would reduce the connection pools to 16. I think this approach
is what the other replier (Bruce) suggested, too.

Of course, .NET Remoting will bring overhead and complicate things a bit,
but scalability is more important to them. I agree that more prudent would
be to run the apps outside the TS in this case, but they have a policy that
dictates that all the apps should be run under it.

-Jemm

 

[David Browne]

pooling
is

Thanks for the reply.
There are also other database apps that take up connections. They claim they
can handle 200 hundred connections at max, but it sounds suspiciously low to
me.

That's just a database setting, it can be changed. Oracle running on my
grandma's laptop can handle hundreds of sessions. Oracle is a great
client/server database, and is built to handle lots of clients. Idle
sessions consume nothing but some memory and an idle OS thread (or unix
process).

Plus if the number of sessions really were a problem, the DBA can put you on
shared-server connections. That's a kind of server-side connection pooling
in Oracle where many connections share a few sessions. It's a little
slower, but you the server can handle thousands of connections that way.
Point is, if the number of connections from your application ever becomes a
problem, you can be switched from dedicated-server to shared-server
connections. And so it's absolute lunacy to architect your application
around an imaginary limit in Oracle connections.


David