Pooling in n-tier architecture

[Jeff Pipes]

I need some advice. I'm designing an n-tier application in .net. I wasn't
sure whether I wanted the data access code to be inside the business objects
or to encapsulate them in separate data access objects. Then I discovered
that ado.net's connection pooling only works on a per process basis. So I've
decided that all data access code would be placed in separate objects residing
on a central server. This will allow us to take advantage of ado.net's connection
pooling. But this potentially creates a new problem. What good does connection
pooling do if the data access objects are being creating and destroyed? Now
I'm thinking that I should implement some sort of object pooling. I'm guessing
that's what com+ does. But another possible solution is to make my data access
objects completely stateless and use shared (static) methods. This should
avoid the issue of the object pooling completely since no object would be
created or destroyed. Any comments or suggestions?

-Jeff

[Kunle Odutola]

> But another possible solution is to make my data access
> objects completely stateless and use shared (static) methods. This should
> avoid the issue of the object pooling completely since no object would be
> created or destroyed. Any comments or suggestions?

Unless you can write your own app server, I'd advise using COM+ services.
Object pooling, connection pooling and a lot of other infrastructural
details have already being taken care of on your behalf.

Kunle

[Jeff Pipes]

"Kunle Odutola" <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:
>
>Unless you can write your own app server, I'd advise using COM+ services.
>Object pooling, connection pooling and a lot of other infrastructural
>details have already being taken care of on your behalf.
>
>Kunle

Well ado.net is going to give me connection pooling anyway. The main advantage
of com+ in this case is the object pooling. But if my data access objects
are static, there should be no need to pool objects since they're never created
or destroyed. Admittedly I'm still new at .net but I'm wondering if this
idea is workable.

-Jeff

[Kunle Odutola]

"Jeff Pipes" <JeffP622@msn.com> wrote in message
news:3cdf095a$1@10.1.10.29...
>
> "Kunle Odutola" <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:
> >
> >Unless you can write your own app server, I'd advise using COM+ services.
> >Object pooling, connection pooling and a lot of other infrastructural
> >details have already being taken care of on your behalf.
> >
> >Kunle
>
> Well ado.net is going to give me connection pooling anyway. The main
advantage
> of com+ in this case is the object pooling. But if my data access objects
> are static,

......you won't be able to use remoting.

Kunle

[Tom Barnaby]

Hi Jeff,

"Jeff Pipes" <JeffP622@msn.com> wrote:
>
>I need some advice. I'm designing an n-tier application in .net. I wasn't
>sure whether I wanted the data access code to be inside the business objects
>or to encapsulate them in separate data access objects. Then I discovered
>that ado.net's connection pooling only works on a per process basis. So
I've
>decided that all data access code would be placed in separate objects residing
>on a central server.

My opinion is that the extra cross-process (cross network?) call for data
access that this design causes would eclipse any gains achieved by pooling
ADO.NET connections across several applications. My advice: separate the
data access code if you think it is necessary, but keep it running in process
relative to the business objects.

What exactly is the issue with ADO.NET per-process pooling scheme?

>This will allow us to take advantage of ado.net's connection
>pooling. But this potentially creates a new problem. What good does connection
>pooling do if the data access objects are being creating and destroyed?

Database connections are expensive to create and destroy. That's why pooling
them is so effective. Your data access objects, on the other hand, are relatively
cheap to create and destroy - assuming they are using pooled connections.
Pooling does not have to be transitive - it is enough to pool the expensive
resource only, not all objects that use the resource.

Now
>I'm thinking that I should implement some sort of object pooling. I'm guessing
>that's what com+ does. But another possible solution is to make my data
access
>objects completely stateless and use shared (static) methods. This should
>avoid the issue of the object pooling completely since no object would be
>created or destroyed. Any comments or suggestions?

Shared methods cannot be remoted. So if your plan is to use the data access
classes in-proc only then I see no problem. This seems to contradict your
earlier plan to move the data access code to a central server though.

Overall, it is unnecessary to pool the data access objects if the connections
are pooled. Also, if a data access object is pooled, it cannot use COM+ transactions
because an ADO.NET connection automatically enlists itself in the transaction.


Tom Barnaby
www.intertech-inc.com

[Rob Teixeira]

If you decide to make your objects stateless (or provide some means for them
to be thread-safe), then you can bypass COM+ altogether by making a Server
Activated Singleton remoting class.
If you aren't going to use COM+ features (such as transaction support and
ability to work with COM clients), it's better to leave it out, since there
will be an overhead for using it above just the RPC stuff.

-Rob

"Jeff Pipes" <JeffP622@msn.com> wrote:
>
>I need some advice. I'm designing an n-tier application in .net. I wasn't
>sure whether I wanted the data access code to be inside the business objects
>or to encapsulate them in separate data access objects. Then I discovered
>that ado.net's connection pooling only works on a per process basis. So
I've
>decided that all data access code would be placed in separate objects residing
>on a central server. This will allow us to take advantage of ado.net's connection
>pooling. But this potentially creates a new problem. What good does connection
>pooling do if the data access objects are being creating and destroyed?
Now
>I'm thinking that I should implement some sort of object pooling. I'm guessing
>that's what com+ does. But another possible solution is to make my data
access
>objects completely stateless and use shared (static) methods. This should
>avoid the issue of the object pooling completely since no object would be
>created or destroyed. Any comments or suggestions?
>
>-Jeff
>

[Jeff Pipes]

"Tom Barnaby" <tbarnaby@intertech-inc.com> wrote:
>
>"Jeff Pipes" <JeffP622@msn.com> wrote:
>
>My opinion is that the extra cross-process (cross network?) call for data
>access that this design causes would eclipse any gains achieved by pooling
>ADO.NET connections across several applications. My advice: separate the
>data access code if you think it is necessary, but keep it running in process
>relative to the business objects.

My plan is/was to have the ui and business objects running on the client,
the data access objects running on a server, and then of course a server
running slq server. So, yes there would be a cross network call.

So let me make sure i understand you. You think it would be better to have
the ui, business objects and the data access objects all running on the client?
Only the db server would be on a separate machine?

>Database connections are expensive to create and destroy. That's why pooling
>them is so effective. Your data access objects, on the other hand, are relatively
>cheap to create and destroy - assuming they are using pooled connections.
>Pooling does not have to be transitive - it is enough to pool the expensive
>resource only, not all objects that use the resource.

OK.

>Shared methods cannot be remoted. So if your plan is to use the data access
>classes in-proc only then I see no problem. This seems to contradict your
>earlier plan to move the data access code to a central server though.

I didn't know you can't use .net remoting with shared methods. I guess that
destroys that idea

>Overall, it is unnecessary to pool the data access objects if the connections
>are pooled. Also, if a data access object is pooled, it cannot use COM+
transactions
>because an ADO.NET connection automatically enlists itself in the transaction.

At this point, there doesn't seem to be a need for me to use com+ transactions.
As I understand it, you only need com+ transactions if you're doing a transaction
over multiple servers.

I didn't mention this yet but this is a windows forms application. At some
future point I would also like to be able to swap out the windows ui and
replace it with a web forms ui.

Thanks Tom for your help.

-Jeff

[Tom Barnaby]

Hey Jeff:

"Jeff Pipes" <JeffP622@msn.com> wrote:
>
>"Tom Barnaby" <tbarnaby@intertech-inc.com> wrote:
>>
>My plan is/was to have the ui and business objects running on the client,
>the data access objects running on a server, and then of course a server
>running slq server. So, yes there would be a cross network call.
>
>So let me make sure i understand you. You think it would be better to have
>the ui, business objects and the data access objects all running on the
client?
>Only the db server would be on a separate machine?
>

Depends on what you mean by "client". ;-) For some reason, I assumed this
was a web application, i.e. the client was ASP.NET. But below you clarify
that this is a traditional app (for now at least). In that context, it does
makes more sense to put the data access objects in their own server. Sorry
about the confusion.

>
>I didn't know you can't use .net remoting with shared methods. I guess that
>destroys that idea
>

Just to be precise, shared methods ALWAYS execute in the context of the caller.
So you can have a remote object with shared methods, its just that the shared
methods will execute locally (this can actually be advantageous at times).

>
>At this point, there doesn't seem to be a need for me to use com+ transactions.
>As I understand it, you only need com+ transactions if you're doing a transaction
>over multiple servers.
>

Yep, that's right. Other reasons to use COM+ tx's: less code and easy to
use distributed txs if needed in the future. But I don't disagree with your
decision not to use COM+.

>I didn't mention this yet but this is a windows forms application. At some
>future point I would also like to be able to swap out the windows ui and
>replace it with a web forms ui.
>

Good to know ;-). For best performance in the web forms case, run the data
access objects in-proc.

Good luck!
Tom Barnaby
www.intertech-inc.com
Distributed .NET Programming in C# (Apress, June)

[Tom Barnaby]

"Rob Teixeira" <RobTeixeira@@msn.com> wrote:
>
>
>If you decide to make your objects stateless (or provide some means for
them
>to be thread-safe), then you can bypass COM+ altogether by making a Server
>Activated Singleton remoting class.
>If you aren't going to use COM+ features (such as transaction support and
>ability to work with COM clients), it's better to leave it out, since there
>will be an overhead for using it above just the RPC stuff.
>
>-Rob
>

Good advice Rob. I agree.

Tom Barnaby

[Jeff Pipes]

So use a singleton remoting class for my data access objects? Is that how
you guys are doing it?

(Sorry to ask so many questions, there doesn't seem to be a lot of guidence
on these types architectural issues.)

-Jeff

"Tom Barnaby" <tbarnaby@intertech-inc.com> wrote:
>
>"Rob Teixeira" <RobTeixeira@@msn.com> wrote:
>>
>>
>>If you decide to make your objects stateless (or provide some means for
>them
>>to be thread-safe), then you can bypass COM+ altogether by making a Server
>>Activated Singleton remoting class.
>>If you aren't going to use COM+ features (such as transaction support and
>>ability to work with COM clients), it's better to leave it out, since there
>>will be an overhead for using it above just the RPC stuff.
>>
>>-Rob
>>
>
>Good advice Rob. I agree.
>
>Tom Barnaby

[Rob Teixeira]

"Jeff Pipes" <JeffP622@msn.com> wrote:
>
>So use a singleton remoting class for my data access objects? Is that how
>you guys are doing it?


Depends on what the issue at hand is. Singleton isn't the solution for everything.
I'll try to summarize quickly.

Remoting (using objects across different app domains) is broken out into
several models:

* Marshal By Value Remoting
+ Serialized objects
* Marshal By Reference Remoting
+ Client Activated objects
+ Server Activated object (wellknown objects)
- Singleton objects
- Single-Call objects

Marshal By Value works kinda like the Star Trek teleporter. It dematerializes
your object into a pattern buffer, beams the data to the remote location,
and your awayteam object gets reconstituted there. From there on out, he's
on the remote planet surface (hopefully, not wearing a red uniform).
Internally, when a Marshal By Value object is transported to the remote app
domain, it's done entirely by serialization, so the object has to support
serialization either through the attribute or the interface. This is good
for (small) objects that collect info on the server and transmit that info
to the client. One very common scenario is remote exception objects.

On the reverse side of the coin, you have Marshal By Reference objects. This
part is more complex. These objects live entirely on the server and do their
work their (with some minor exceptions). The client receives a proxy that
it communicates with as if it were the object, but the proxy does all the
grunt work of sending messages to the server where the real work is done,
and then taking care of the return data.
The main differences between the types of byRef remoting is how long the
objects live and who owns their lifetimes.

* Client activated objects get created for each unique client refernce. If
a client instanciates 10 references, it gets 10 objects. The lifetime of
these objects on the server is dictated by a lifetime lease. The client can
renew leases, or simply extend them by continously making calls to the object.
When the lease expires (probably because there was no activity on the object)
the server kills it.

* Single Call objects exist for the span of one call. Even if a client maintains
a reference to the server object, the real object is available for only one
call. Needless to say, these objects must be stateless.

* A Singleton object is just that. Only one object exists on the server app
domain, and it services all client requests. It does not have to be stateless,
but it must be thread-safe.

Based on this info, you have to pick what's right for your scenario.

-Rob


>(Sorry to ask so many questions, there doesn't seem to be a lot of guidence
>on these types architectural issues.)
>
>-Jeff
>
>"Tom Barnaby" <tbarnaby@intertech-inc.com> wrote:
>>
>>"Rob Teixeira" <RobTeixeira@@msn.com> wrote:
>>>
>>>
>>>If you decide to make your objects stateless (or provide some means for
>>them
>>>to be thread-safe), then you can bypass COM+ altogether by making a Server
>>>Activated Singleton remoting class.
>>>If you aren't going to use COM+ features (such as transaction support
and
>>>ability to work with COM clients), it's better to leave it out, since
there
>>>will be an overhead for using it above just the RPC stuff.
>>>
>>>-Rob
>>>
>>
>>Good advice Rob. I agree.
>>
>>Tom Barnaby
>

[Jeff Pipes]

Thanks for the great summation. Obviously I need to do some research on remoting.
But I am curious as to what other developers are doing. How are you architecting
your data access layer?

-Jeff

"Rob Teixeira" <RobTeixeira@@msn.com> wrote:
>
>"Jeff Pipes" <JeffP622@msn.com> wrote:
>>
>
>Depends on what the issue at hand is. Singleton isn't the solution for everything.
>I'll try to summarize quickly.
>
>Remoting (using objects across different app domains) is broken out into
>several models:
>
>* Marshal By Value Remoting
> + Serialized objects
>* Marshal By Reference Remoting
> + Client Activated objects
> + Server Activated object (wellknown objects)
> - Singleton objects
> - Single-Call objects
>
>Marshal By Value works kinda like the Star Trek teleporter. It dematerializes
>your object into a pattern buffer, beams the data to the remote location,
>and your awayteam object gets reconstituted there. From there on out, he's
>on the remote planet surface (hopefully, not wearing a red uniform).
>Internally, when a Marshal By Value object is transported to the remote
app
>domain, it's done entirely by serialization, so the object has to support
>serialization either through the attribute or the interface. This is good
>for (small) objects that collect info on the server and transmit that info
>to the client. One very common scenario is remote exception objects.
>
>On the reverse side of the coin, you have Marshal By Reference objects.
This
>part is more complex. These objects live entirely on the server and do their
>work their (with some minor exceptions). The client receives a proxy that
>it communicates with as if it were the object, but the proxy does all the
>grunt work of sending messages to the server where the real work is done,
>and then taking care of the return data.
>The main differences between the types of byRef remoting is how long the
>objects live and who owns their lifetimes.
>
>* Client activated objects get created for each unique client refernce.
If
>a client instanciates 10 references, it gets 10 objects. The lifetime of
>these objects on the server is dictated by a lifetime lease. The client
can
>renew leases, or simply extend them by continously making calls to the object.
>When the lease expires (probably because there was no activity on the object)
>the server kills it.
>
>* Single Call objects exist for the span of one call. Even if a client maintains
>a reference to the server object, the real object is available for only
one
>call. Needless to say, these objects must be stateless.
>
>* A Singleton object is just that. Only one object exists on the server
app
>domain, and it services all client requests. It does not have to be stateless,
>but it must be thread-safe.
>
>Based on this info, you have to pick what's right for your scenario.
>
>-Rob