MBR IT/.NET 247 : COM+ vs. remoting on ASPFriends.com 'ngfx-remoting' list

COM+ vs. remoting

Messages

Related Types

This message was discovered on ASPFriends.com 'ngfx-remoting' list.

Vishnu DotNet

Hi,
I know that COM+ provides many services such as object pooling and
transaction. However, COM+ has overheads and I am looking for
managed code that does object pooling in .NET (possibly using
remoting).
Any idea or link that shows such thing?

Thanks.
-Vishnu

_________________________________________________________
There is always a better job for you at Monsterindia.com.
Go now http://monsterindia.rediff.com/jobs

Reply to this message...

Derek Beyer

Hi Vishnu,

The only object pooling in .Net *is* COM+ (actually Enterprise Services in
.NET) object pooling. And that goes for the rest of the services in COM+ as
well. IMHO, the overhead of Enterprise Services should be outweighed by the
benefits of a properly designed pooled component.

----- Original Message -----
From: "Vishnu DotNet" <Click here to reveal e-mail address>
To: "ngfx-remoting" <Click here to reveal e-mail address>
Sent: Tuesday, July 09, 2002 12:24 AM
Subject: [ngfx-remoting] COM+ vs. remoting

[Original message clipped]

Reply to this message...

Vishnu DotNet

Hi Derek,
Thanks for your reply. However, my intention is to have managed
solution to the problem. I came across one article at
http://www.csharphelp.com/archives/archive285.html that explains
doing object pool in .NET but it is for local objects. I want to
have remoting support also. Any idea as to how to do that?

Thanks.
-Vishnu

On Wed, 10 Jul 2002 Derek Beyer wrote :
[Original message clipped]

_________________________________________________________
There is always a better job for you at Monsterindia.com.
Go now http://monsterindia.rediff.com/jobs

Reply to this message...

Derek Beyer

hmm, interesting article.

given this scenario, you could have two remotable classes:
1. the pool manager class (similar to the ObjectPool class used in the
article)
2. the actual class you want to pool

each of these classes would have to inherit either directly or indirectly
from System.MarshalByRefObject. Simply stated this class tells .NET that the
derived class is remotable.

You would probably want to implement some kind of factory design pattern in
the pool manager class. that way the pool manager class could hide the
implementation of the stack and the thread pool, all the while returning
instances of the pooled class. I am envisioning a method called something
like "object PooledClass.CreateInstance(Type t, object args)". Where the
object returned is your pooled component. If you derive this class from
MarshalByRefObject, it will stay on the server where it belongs. After all,
what's the point of having an object pool where the pooled objects are
passed all over the network?

The question here is whether to make the pool manager class a singlecall or
singleton. You would want it to be a singleton object since only once
instance of a singleton is created per server (technically probably per
URI). Unless I am missing something, you would not need to make this
consideration for the pooled class since your pool manager is creating the
instances. Simply deriving from MarshalByRefObject will keep the pooled
class on the [remote] server.

I hope this helps somewhat. This is a very high level view of what you would
need to do to make this work. I don't mean to pick on the article or the
author by any means, but there is a number of things you would have to do to
make this code work in a remoting scenario. The fundamental problem with
example is that that management of the pool is spread out between the
ObjectContext class, the ObjectPool class and the client. For example, the
client is responsible for telling the ObjectContext to push itself onto the
stack!

Before you head down this path, please understand that .NET Remoting and
Enterprise Services are *very* tightly integrated. Understanding Enterprise
Services in .NET
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/h
tml/entserv.asp) is a great read if you want to understand the activation
process for ServicedComponents and how .NET Remoting comes into play. Afer
all, the ServicedComponent class that you have to derive from when you
create a COM+ component, inherits indirectly from MarshalByRefObject so
remoting is built in! The good thing about using Enterprise Services for
object pooling and remoting is that you get to combine other COM+ features
as well. Take Just-in-Time activation (JIT) and "as soon as possible
deactivation" for example. In the scenario mentioned above, the client hold
a reference to the object the entire time and the object cannot go back to
the pool - until *in theory* the client Dispose's of the object and the
object returns to the pool (although returning an object back to the pool is
not implented in this example either). If you were running in COM+, JIT
would allow you to return the object back to the pool after each method call
(assuming the proper bit flags get set) which in turn would make the object
available to another client. So now two clients could be using the same
object instance all the while thinking they had their own reference to the
object. This is a great opportunity for scalability isn't it!? :-)

As you can see, this is not a trivial issue. I've glossed over a great deal
of issues and made some big assumptions here, but hopefully we have seen
some of the implications of implementing our own object pool.

Derek

----- Original Message -----
From: "Vishnu DotNet" <Click here to reveal e-mail address>
To: "ngfx-remoting" <Click here to reveal e-mail address>
Sent: Tuesday, July 09, 2002 10:55 PM
Subject: [ngfx-remoting] Re: COM+ vs. remoting

[Original message clipped]

Reply to this message...

	System.EnterpriseServices.ServicedComponent
	System.MarshalByRefObject

MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT

	Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
	Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com