Pooling in n-tier architecture


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 12 of 12

Thread: Pooling in n-tier architecture

Hybrid View

  1. #1
    Jeff Pipes Guest

    Pooling in n-tier architecture


    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


  2. #2
    Kunle Odutola Guest

    Re: Pooling in n-tier architecture


    > 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



  3. #3
    Jeff Pipes Guest

    Re: Pooling in n-tier architecture


    "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

  4. #4
    Tom Barnaby Guest

    Re: Pooling in n-tier architecture


    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



  5. #5
    Rob Teixeira Guest

    Re: Pooling in n-tier architecture



    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
    >



  6. #6
    Jeff Pipes Guest

    Re: Pooling in n-tier architecture


    "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

  7. #7
    Tom Barnaby Guest

    Re: Pooling in n-tier architecture


    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)

  8. #8
    Tom Barnaby Guest

    Re: Pooling in n-tier architecture


    "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

  9. #9
    Kunle Odutola Guest

    Re: Pooling in n-tier architecture


    "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



  10. #10
    Jeff Pipes Guest

    Re: Pooling in n-tier architecture


    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



  11. #11
    Rob Teixeira Guest

    Re: Pooling in n-tier architecture


    "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

    >



  12. #12
    Jeff Pipes Guest

    Re: Pooling in n-tier architecture


    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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center