Asp Forum - Re: Remoting Singleton with strongly typed collection in it - microsoft.public.dotnet.framework.remoting

Sam Santiago

7/30/2004 7:37:00 PM

You are marshaling your class ENVStatus.ENVStatusCollectionTest by value
since it does not inherit from MarshalByRefObject, so you simply have to
mark your class as serializable as the error says:

<Serializable()> _
Public Class ENVStatusCollectionTest
Inherits NameObjectCollectionBase...

Check out this link:

Remotable Objects
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconremotableo...

Thanks,

Sam
--
_______________________________
Sam Santiago
ssantiago@n0spam-SoftiTechture.com
http://www.SoftiTe...
_______________________________
"Terry" <Terry@discussions.microsoft.com> wrote in message
news:BCE84032-679F-40ED-8F2F-C607CBFC5F81@microsoft.com...
> How can I inherit MarshalByReference in a class that already has an
inheritance?
>
> I am trying to set up a singleton object that multiple clients conncect
to. In the object is a strongly typed "collection" based on
NameObjectCollectionBase. In my remote client I can reference the object
and it's non-collection properties, but when I try to get something from the
collection within it I get the following error:
>
> An unhandled exception of type
'System.Runtime.Serialization.SerializationException' occurred in
mscorlib.dll
> Additional information: The type ENVStatus.ENVStatusCollectionTest in
Assembly ENVStatus, Version=1.0.1672.25241, Culture=neutral,
PublicKeyToken=null is not marked as serializable.
>
> Here is the class that I remote and the collection property within it
>
> Public Class ENVStatusMasterTest
> Inherits MarshalByRefObject
>
> Private strENVStatusMasterID As String
> Property ENVStatusMasterID() As String
> Get
> Return strENVStatusMasterID
> End Get
> Set(ByVal Value As String)
> strENVStatusMasterID = Value
> End Set
> End Property
>
> Private objENVStatus As New ENVStatusCollectionTest
> ' Unique System Identifier
> Property ENVStatus() As ENVStatusCollectionTest
> Get
> Return objENVStatus
> End Get
> Set(ByVal Value As ENVStatusCollectionTest)
> objENVStatus = Value
> End Set
> End Property
> End Class
>
> Public Class ENVStatusCollectionTest
> Inherits NameObjectCollectionBase
> Default Property ENVStatus(ByVal pkey As String) As ENVStatusTest
> Get
> Return DirectCast(Me.BaseGet(pkey), ENVStatusTest)
> End Get
> Set(ByVal Value As ENVStatusTest)
> Me.BaseSet(pkey, Value)
> End Set
> End Property
> Default Property ENVStatus(ByVal pindex As Integer) As ENVStatusTest
> Get
> Return DirectCast(Me.BaseGet(pindex), ENVStatusTest)
> End Get
> Set(ByVal Value As ENVStatusTest)
> Me.BaseSet(pindex, Value)
> End Set
> End Property
>
> Sub Add(ByVal pkey As String, ByVal pENVStatus As ENVStatusTest)
> Me.BaseAdd(pkey, pENVStatus)
> End Sub
> Overloads Sub Remove(ByVal pkey As String)
> Me.BaseRemove(pkey)
> End Sub
> Overloads Sub Remove(ByVal pkey As Integer)
> Me.BaseRemove(pkey)
> End Sub
> Sub Clear()
> Me.BaseClear()
> End Sub
> End Class

14 Answers

Terry

7/30/2004 8:17:00 PM

Thanks Sam.. I did that and got the following error:

An unhandled exception of type 'System.Runtime.Serialization.SerializationException' occurred in mscorlib.dll
Additional information: The constructor to deserialize an object of type ENVStatus.ENVStatusCollectionTest was not found.

PLEASE READ THE REST HERE:

This is the same error I got when I tried to remote a singleton object that had a collection in it. When I changed the collection to a SortedList or ArrayList it remoted fine. Now I am using a strongly type class and need to be able to remote to this singleton object (e.g. I want to marshall by Reference NOT Value, to that there is only one instance of the class that multiple client access.)

Bottom line, I only want one copy of the object that resides at the server. The clients simply have pointers to it. The only time data moves across the connection is if a property or method is referenced by the client. All clients get the same data at the same time. Very important for this manufacturing control application.

Please advise,
Terry

"Sam Santiago" wrote:

> You are marshaling your class ENVStatus.ENVStatusCollectionTest by value
> since it does not inherit from MarshalByRefObject, so you simply have to
> mark your class as serializable as the error says:
>
> <Serializable()> _
> Public Class ENVStatusCollectionTest
> Inherits NameObjectCollectionBase...
>
> Check out this link:
>
> Remotable Objects
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconremotableo...
>
> Thanks,
>
> Sam
> --
> _______________________________
> Sam Santiago
> ssantiago@n0spam-SoftiTechture.com
> http://www.SoftiTe...
> _______________________________
> "Terry" <Terry@discussions.microsoft.com> wrote in message
> news:BCE84032-679F-40ED-8F2F-C607CBFC5F81@microsoft.com...
> > How can I inherit MarshalByReference in a class that already has an
> inheritance?
> >
> > I am trying to set up a singleton object that multiple clients conncect
> to. In the object is a strongly typed "collection" based on
> NameObjectCollectionBase. In my remote client I can reference the object
> and it's non-collection properties, but when I try to get something from the
> collection within it I get the following error:
> >
> > An unhandled exception of type
> 'System.Runtime.Serialization.SerializationException' occurred in
> mscorlib.dll
> > Additional information: The type ENVStatus.ENVStatusCollectionTest in
> Assembly ENVStatus, Version=1.0.1672.25241, Culture=neutral,
> PublicKeyToken=null is not marked as serializable.
> >
> > Here is the class that I remote and the collection property within it
> >
> > Public Class ENVStatusMasterTest
> > Inherits MarshalByRefObject
> >
> > Private strENVStatusMasterID As String
> > Property ENVStatusMasterID() As String
> > Get
> > Return strENVStatusMasterID
> > End Get
> > Set(ByVal Value As String)
> > strENVStatusMasterID = Value
> > End Set
> > End Property
> >
> > Private objENVStatus As New ENVStatusCollectionTest
> > ' Unique System Identifier
> > Property ENVStatus() As ENVStatusCollectionTest
> > Get
> > Return objENVStatus
> > End Get
> > Set(ByVal Value As ENVStatusCollectionTest)
> > objENVStatus = Value
> > End Set
> > End Property
> > End Class
> >
> > Public Class ENVStatusCollectionTest
> > Inherits NameObjectCollectionBase
> > Default Property ENVStatus(ByVal pkey As String) As ENVStatusTest
> > Get
> > Return DirectCast(Me.BaseGet(pkey), ENVStatusTest)
> > End Get
> > Set(ByVal Value As ENVStatusTest)
> > Me.BaseSet(pkey, Value)
> > End Set
> > End Property
> > Default Property ENVStatus(ByVal pindex As Integer) As ENVStatusTest
> > Get
> > Return DirectCast(Me.BaseGet(pindex), ENVStatusTest)
> > End Get
> > Set(ByVal Value As ENVStatusTest)
> > Me.BaseSet(pindex, Value)
> > End Set
> > End Property
> >
> > Sub Add(ByVal pkey As String, ByVal pENVStatus As ENVStatusTest)
> > Me.BaseAdd(pkey, pENVStatus)
> > End Sub
> > Overloads Sub Remove(ByVal pkey As String)
> > Me.BaseRemove(pkey)
> > End Sub
> > Overloads Sub Remove(ByVal pkey As Integer)
> > Me.BaseRemove(pkey)
> > End Sub
> > Sub Clear()
> > Me.BaseClear()
> > End Sub
> > End Class
>
>
>

Sam Santiago

7/30/2004 9:59:00 PM

I think this error is caused by the fact that your client does not have the
metadata related to your ENVStatusCollectionTest class. Check out this link
and read #5 on metadata:

Basic Remoting Task List
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconBasicRemotingTaskList.asp?...

Your ENVStatusMasterTest is configured as a Singleton SAO. But the
ENVStatus property for it is another object. Do you want this object -
ENVStatusCollectionTest - to be Singleton SAO too (a remotable object that
is marshaled by reference, MBR) or do you want it to be marshaled-by-value,
MBV. If you want it to be MBV then it must be serializable. If you want
MBR then your class must inherit from the MarshalByRefObject class, but
since you are already inheriting the NameObjectCollectionBase you'll have to
create a wrapper class that inherits from MarshalByRefObject , but contains
a NameObjectCollectionBase member.

More complications follow. If the ENVStatusCollectionTest is defined to be
MBR then by default it will be treated as a CAO when it is returned by the
ENVStatusMasterTest. .NET Remoting by default treats all MBR objects as
CAOs if they are created indirectly by another remoted object and returned
to the client. If you want to return a SAO to the client then you have to
create your object using Activator.GetObject and marshal it yourself.
Here's an example:

On the Server side:

' This is a method inside of a Singleton SAO to return a reference to
another Singleton SAO to the client.
Public Function Return_SAO_to_Client() As ObjRef
Dim BO As MyMBR
BO = CType(Activator.GetObject(GetType(MyMBR),
"http://localhost:8085/MyMBR"), MyMBR)
Return RemotingServices.Marshal(BO)
End Function

On the ClientSide:

Dim tempbo As MyMBR
tempbo = CType(RemotingServices.Unmarshal(myRootSAO.Return_SAO_to_Client),
MyMBR)

Either way, you have to ensure your client has access to the metadata of
your remote object.

Thanks,

Sam

--
_______________________________
Sam Santiago
ssantiago@n0spam-SoftiTechture.com
http://www.SoftiTe...
_______________________________
"Terry" <Terry@discussions.microsoft.com> wrote in message
news:BADF67FD-647B-4EE2-A8D3-CB544B4BA32E@microsoft.com...
> Thanks Sam.. I did that and got the following error:
>
> An unhandled exception of type
'System.Runtime.Serialization.SerializationException' occurred in
mscorlib.dll
> Additional information: The constructor to deserialize an object of type
ENVStatus.ENVStatusCollectionTest was not found.
>
> PLEASE READ THE REST HERE:
>
> This is the same error I got when I tried to remote a singleton object
that had a collection in it. When I changed the collection to a SortedList
or ArrayList it remoted fine. Now I am using a strongly type class and need
to be able to remote to this singleton object (e.g. I want to marshall by
Reference NOT Value, to that there is only one instance of the class that
multiple client access.)
>
> Bottom line, I only want one copy of the object that resides at the
server. The clients simply have pointers to it. The only time data moves
across the connection is if a property or method is referenced by the
client. All clients get the same data at the same time. Very important for
this manufacturing control application.
>
> Please advise,
> Terry
>
> "Sam Santiago" wrote:
>
> > You are marshaling your class ENVStatus.ENVStatusCollectionTest by
value
> > since it does not inherit from MarshalByRefObject, so you simply have to
> > mark your class as serializable as the error says:
> >
> > <Serializable()> _
> > Public Class ENVStatusCollectionTest
> > Inherits NameObjectCollectionBase...
> >
> > Check out this link:
> >
> > Remotable Objects
> >
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconremotableo...
> >
> > Thanks,
> >
> > Sam
> > --
> > _______________________________
> > Sam Santiago
> > ssantiago@n0spam-SoftiTechture.com
> > http://www.SoftiTe...
> > _______________________________
> > "Terry" <Terry@discussions.microsoft.com> wrote in message
> > news:BCE84032-679F-40ED-8F2F-C607CBFC5F81@microsoft.com...
> > > How can I inherit MarshalByReference in a class that already has an
> > inheritance?
> > >
> > > I am trying to set up a singleton object that multiple clients
conncect
> > to. In the object is a strongly typed "collection" based on
> > NameObjectCollectionBase. In my remote client I can reference the
object
> > and it's non-collection properties, but when I try to get something from
the
> > collection within it I get the following error:
> > >
> > > An unhandled exception of type
> > 'System.Runtime.Serialization.SerializationException' occurred in
> > mscorlib.dll
> > > Additional information: The type ENVStatus.ENVStatusCollectionTest in
> > Assembly ENVStatus, Version=1.0.1672.25241, Culture=neutral,
> > PublicKeyToken=null is not marked as serializable.
> > >
> > > Here is the class that I remote and the collection property within it
> > >
> > > Public Class ENVStatusMasterTest
> > > Inherits MarshalByRefObject
> > >
> > > Private strENVStatusMasterID As String
> > > Property ENVStatusMasterID() As String
> > > Get
> > > Return strENVStatusMasterID
> > > End Get
> > > Set(ByVal Value As String)
> > > strENVStatusMasterID = Value
> > > End Set
> > > End Property
> > >
> > > Private objENVStatus As New ENVStatusCollectionTest
> > > ' Unique System Identifier
> > > Property ENVStatus() As ENVStatusCollectionTest
> > > Get
> > > Return objENVStatus
> > > End Get
> > > Set(ByVal Value As ENVStatusCollectionTest)
> > > objENVStatus = Value
> > > End Set
> > > End Property
> > > End Class
> > >
> > > Public Class ENVStatusCollectionTest
> > > Inherits NameObjectCollectionBase
> > > Default Property ENVStatus(ByVal pkey As String) As ENVStatusTest
> > > Get
> > > Return DirectCast(Me.BaseGet(pkey), ENVStatusTest)
> > > End Get
> > > Set(ByVal Value As ENVStatusTest)
> > > Me.BaseSet(pkey, Value)
> > > End Set
> > > End Property
> > > Default Property ENVStatus(ByVal pindex As Integer) As ENVStatusTest
> > > Get
> > > Return DirectCast(Me.BaseGet(pindex), ENVStatusTest)
> > > End Get
> > > Set(ByVal Value As ENVStatusTest)
> > > Me.BaseSet(pindex, Value)
> > > End Set
> > > End Property
> > >
> > > Sub Add(ByVal pkey As String, ByVal pENVStatus As ENVStatusTest)
> > > Me.BaseAdd(pkey, pENVStatus)
> > > End Sub
> > > Overloads Sub Remove(ByVal pkey As String)
> > > Me.BaseRemove(pkey)
> > > End Sub
> > > Overloads Sub Remove(ByVal pkey As Integer)
> > > Me.BaseRemove(pkey)
> > > End Sub
> > > Sub Clear()
> > > Me.BaseClear()
> > > End Sub
> > > End Class
> >
> >
> >

Sunny

7/31/2004 8:36:00 PM

Hi,

In article <OBL0yBodEHA.1656@TK2MSFTNGP09.phx.gbl>, ssantiago@n0spam-
SoftiTechture.com says...
> I think this error is caused by the fact that your client does not have the
> metadata related to your ENVStatusCollectionTest class. Check out this link
> and read #5 on metadata:
>
> Basic Remoting Task List
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconBasicRemotingTaskList.asp?...
>
> Your ENVStatusMasterTest is configured as a Singleton SAO. But the
> ENVStatus property for it is another object. Do you want this object -
> ENVStatusCollectionTest - to be Singleton SAO too (a remotable object that
> is marshaled by reference, MBR) or do you want it to be marshaled-by-value,
> MBV. If you want it to be MBV then it must be serializable. If you want
> MBR then your class must inherit from the MarshalByRefObject class, but
> since you are already inheriting the NameObjectCollectionBase you'll have to
> create a wrapper class that inherits from MarshalByRefObject , but contains
> a NameObjectCollectionBase member.

Right, a wrapper object, inherited from MBR, and only forwarding calls
to the private member collection is the way to go.

>
> More complications follow. If the ENVStatusCollectionTest is defined to be
> MBR then by default it will be treated as a CAO when it is returned by the
> ENVStatusMasterTest. .NET Remoting by default treats all MBR objects as
> CAOs if they are created indirectly by another remoted object and returned
> to the client. If you want to return a SAO to the client then you have to
> create your object using Activator.GetObject and marshal it yourself.

I can not agree here. Please read my answer to your post. What you mean
by "remoting threats"? Remoting is only the possibility to marshal
objects across appdomains. All other is added value, like prebuild
channels, prebuild formatters, prebuild object creation and exposing,
etc.

How an object is treated depends only on you and your application. If
you use the buildin helpers (like config file registrations, or helper
methods like RegisterWellKnown...) this is another story.

Sunny

Sam Santiago

8/1/2004 5:28:00 PM

How you use a remote object does not alone determine whether it is a CAO or
SAO. They are different and the key fundamental difference between an SAO
and CAO is their lifetime management with leases. SAO lifetimes are
controlled by the server, whereas CAO lifetimes are controlled by the
client. If you attempt to use a CAO as a singleton that services all
clients it's lifetime will be controlled by the first client that creates
it. Even if you give this CAO a lifetime lease, it is not the same as a
lifetime lease on an SAO. As soon as the reference from the first client
goes out of scope or is set to nothing your CAO singleton will be recycled
on the server once it's lease expires. Below are some references to an MSDN
article and the .NET documentation that discusses this in more depth.

Client Activation
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconclientacti...

Here's an excerpt:

The client might even request an indefinite default lifetime, effectively
preventing the remote object from ever being recycled until the server
application domain is torn down. The difference between this and a
server-activated indefinite lifetime is that an indefinite server-activated
object will serve all client requests for that type, whereas the
client-activated instances serve only the client and the reference that was
responsible for their creation.

Managing the Lifetime of Remote .NET Objects with Leasing and Sponsorship by
Juval Lowy
http://msdn.microsoft.com/msdnmag/issues/03/12/LeaseManager/de...

Here's an excerpt:

The case of the client-activated object is the one affected most by the
leasing mechanism. When using a client-activated model, every client that
creates a new object gets a dedicated server object. That object's lifetime
is governed by a lease, and the object will be disconnected from the clients
once its lease has expired. The only safe way to manage client-activated
objects is to use sponsors. All other options, such as global lease
properties or configuring individual objects' leases, are speculative at
best. Ultimately, only the client knows when it no longer needs the object.

--
_______________________________
Sam Santiago
ssantiago@n0spam-SoftiTechture.com
http://www.SoftiTe...
_______________________________
"Sunny" <sunny@newsgroups.nospam> wrote in message
news:%239Q2I4zdEHA.2376@tk2msftngp13.phx.gbl...
> Hi,
>
>
> In article <OBL0yBodEHA.1656@TK2MSFTNGP09.phx.gbl>, ssantiago@n0spam-
> SoftiTechture.com says...
> > I think this error is caused by the fact that your client does not have
the
> > metadata related to your ENVStatusCollectionTest class. Check out this
link
> > and read #5 on metadata:
> >
> > Basic Remoting Task List
> >
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconBasicRemotingTaskList.asp?...
> >
> > Your ENVStatusMasterTest is configured as a Singleton SAO. But the
> > ENVStatus property for it is another object. Do you want this object -
> > ENVStatusCollectionTest - to be Singleton SAO too (a remotable object
that
> > is marshaled by reference, MBR) or do you want it to be
marshaled-by-value,
> > MBV. If you want it to be MBV then it must be serializable. If you
want
> > MBR then your class must inherit from the MarshalByRefObject class, but
> > since you are already inheriting the NameObjectCollectionBase you'll
have to
> > create a wrapper class that inherits from MarshalByRefObject , but
contains
> > a NameObjectCollectionBase member.
>
> Right, a wrapper object, inherited from MBR, and only forwarding calls
> to the private member collection is the way to go.
>
> >
> > More complications follow. If the ENVStatusCollectionTest is defined to
be
> > MBR then by default it will be treated as a CAO when it is returned by
the
> > ENVStatusMasterTest. .NET Remoting by default treats all MBR objects as
> > CAOs if they are created indirectly by another remoted object and
returned
> > to the client. If you want to return a SAO to the client then you have
to
> > create your object using Activator.GetObject and marshal it yourself.
>
> I can not agree here. Please read my answer to your post. What you mean
> by "remoting threats"? Remoting is only the possibility to marshal
> objects across appdomains. All other is added value, like prebuild
> channels, prebuild formatters, prebuild object creation and exposing,
> etc.
>
> How an object is treated depends only on you and your application. If
> you use the buildin helpers (like config file registrations, or helper
> methods like RegisterWellKnown...) this is another story.
>
> Sunny

Sam Santiago

8/1/2004 5:34:00 PM

Here's a link where you can download an example showing the differences
between CAO and SAO objects created by a Factory remote object:
http://www.softitechture.com/di...

Thanks,

Sam

--
_______________________________
Sam Santiago
ssantiago@n0spam-SoftiTechture.com
http://www.SoftiTe...
_______________________________
"Sam Santiago" <ssantiago@n0spam-SoftiTechture.com> wrote in message
news:eY0tlz%23dEHA.1356@TK2MSFTNGP09.phx.gbl...
> How you use a remote object does not alone determine whether it is a CAO
or
> SAO. They are different and the key fundamental difference between an SAO
> and CAO is their lifetime management with leases. SAO lifetimes are
> controlled by the server, whereas CAO lifetimes are controlled by the
> client. If you attempt to use a CAO as a singleton that services all
> clients it's lifetime will be controlled by the first client that creates
> it. Even if you give this CAO a lifetime lease, it is not the same as a
> lifetime lease on an SAO. As soon as the reference from the first client
> goes out of scope or is set to nothing your CAO singleton will be recycled
> on the server once it's lease expires. Below are some references to an
MSDN
> article and the .NET documentation that discusses this in more depth.
>
>
> Client Activation
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconclientacti...
>
> Here's an excerpt:
>
> The client might even request an indefinite default lifetime, effectively
> preventing the remote object from ever being recycled until the server
> application domain is torn down. The difference between this and a
> server-activated indefinite lifetime is that an indefinite
server-activated
> object will serve all client requests for that type, whereas the
> client-activated instances serve only the client and the reference that
was
> responsible for their creation.
>
> Managing the Lifetime of Remote .NET Objects with Leasing and Sponsorship
by
> Juval Lowy
> http://msdn.microsoft.com/msdnmag/issues/03/12/LeaseManager/de...
>
> Here's an excerpt:
>
> The case of the client-activated object is the one affected most by the
> leasing mechanism. When using a client-activated model, every client that
> creates a new object gets a dedicated server object. That object's
lifetime
> is governed by a lease, and the object will be disconnected from the
clients
> once its lease has expired. The only safe way to manage client-activated
> objects is to use sponsors. All other options, such as global lease
> properties or configuring individual objects' leases, are speculative at
> best. Ultimately, only the client knows when it no longer needs the
object.
>
> --
> _______________________________
> Sam Santiago
> ssantiago@n0spam-SoftiTechture.com
> http://www.SoftiTe...
> _______________________________
> "Sunny" <sunny@newsgroups.nospam> wrote in message
> news:%239Q2I4zdEHA.2376@tk2msftngp13.phx.gbl...
> > Hi,
> >
> >
> > In article <OBL0yBodEHA.1656@TK2MSFTNGP09.phx.gbl>, ssantiago@n0spam-
> > SoftiTechture.com says...
> > > I think this error is caused by the fact that your client does not
have
> the
> > > metadata related to your ENVStatusCollectionTest class. Check out
this
> link
> > > and read #5 on metadata:
> > >
> > > Basic Remoting Task List
> > >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconBasicRemotingTaskList.asp?...
> > >
> > > Your ENVStatusMasterTest is configured as a Singleton SAO. But the
> > > ENVStatus property for it is another object. Do you want this
object -
> > > ENVStatusCollectionTest - to be Singleton SAO too (a remotable object
> that
> > > is marshaled by reference, MBR) or do you want it to be
> marshaled-by-value,
> > > MBV. If you want it to be MBV then it must be serializable. If you
> want
> > > MBR then your class must inherit from the MarshalByRefObject class,
but
> > > since you are already inheriting the NameObjectCollectionBase you'll
> have to
> > > create a wrapper class that inherits from MarshalByRefObject , but
> contains
> > > a NameObjectCollectionBase member.
> >
> > Right, a wrapper object, inherited from MBR, and only forwarding calls
> > to the private member collection is the way to go.
> >
> > >
> > > More complications follow. If the ENVStatusCollectionTest is defined
to
> be
> > > MBR then by default it will be treated as a CAO when it is returned by
> the
> > > ENVStatusMasterTest. .NET Remoting by default treats all MBR objects
as
> > > CAOs if they are created indirectly by another remoted object and
> returned
> > > to the client. If you want to return a SAO to the client then you
have
> to
> > > create your object using Activator.GetObject and marshal it yourself.
> >
> > I can not agree here. Please read my answer to your post. What you mean
> > by "remoting threats"? Remoting is only the possibility to marshal
> > objects across appdomains. All other is added value, like prebuild
> > channels, prebuild formatters, prebuild object creation and exposing,
> > etc.
> >
> > How an object is treated depends only on you and your application. If
> > you use the buildin helpers (like config file registrations, or helper
> > methods like RegisterWellKnown...) this is another story.
> >
> > Sunny
>
>

Ken Kolda

8/2/2004 5:01:00 PM

See comments inline below...

> > How you use a remote object does not alone determine whether it is a CAO
> or
> > SAO. They are different and the key fundamental difference between an
SAO
> > and CAO is their lifetime management with leases. SAO lifetimes are
> > controlled by the server, whereas CAO lifetimes are controlled by the
> > client. If you attempt to use a CAO as a singleton that services all
> > clients it's lifetime will be controlled by the first client that
creates
> > it. Even if you give this CAO a lifetime lease, it is not the same as a
> > lifetime lease on an SAO. As soon as the reference from the first
client
> > goes out of scope or is set to nothing your CAO singleton will be
recycled
> > on the server once it's lease expires. Below are some references to an
> MSDN
> > article and the .NET documentation that discusses this in more depth.

For a CAO you said "it's lifetime will be controlled by the first client
that creates it" and that its lifetime is somehow dependent upon whether the
client holds a reference to the object or not. None of that is correct. The
lifetime of every remoted object (SAO or CAO) is controlled exclusively by
its lifetime lease and any sponsors registered for the object. It has
nothing to do with whether a client's reference goes out of scope, is set to
null, the client shuts down, etc. When the lease expires (assuming there's
no sponsor to renew it), that's it -- the object is disconnected from the
remoting architecture by the server. In fact, this may happen while the
client still has a reference to the object if the client has failed to setup
a sponsor, in which case, if the client attempts to use it, a "Request
service not found" exception is thrown.

The big difference between an SAO and a CAO is how the client's remoting
framework generates the proxy for the object. For an SAO, the proxy is
created by client with no info required from the server. For a CAO, the
proxy is created from an ObjRef returned by the server which contains, among
other things, the URL for the object. The lifetime management of the two
object types is identical.

> > Client Activation
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconclientacti...
> >
> > Here's an excerpt:
> >
> > The client might even request an indefinite default lifetime,
effectively
> > preventing the remote object from ever being recycled until the server
> > application domain is torn down. The difference between this and a
> > server-activated indefinite lifetime is that an indefinite
> server-activated
> > object will serve all client requests for that type, whereas the
> > client-activated instances serve only the client and the reference that
> was
> > responsible for their creation.

On the MSDN site, they generally use the term "client activation" to refer
to remote objects created thru calls to either Activator.CreateObject() or
using "new" when the type has been registered as a client-activated type. In
this case, it's not possible for two clients to share the same instance
because it's the remoting framework which is instantiating the objects. But,
if you use a factory pattern and instantiate your own CAO's, there's nothing
to prevent you from returning the same CAO to multiple clients.

> >
> > Managing the Lifetime of Remote .NET Objects with Leasing and
Sponsorship
> by
> > Juval Lowy
> > http://msdn.microsoft.com/msdnmag/issues/03/12/LeaseManager/de...
> >
> > Here's an excerpt:
> >
> > The case of the client-activated object is the one affected most by the
> > leasing mechanism. When using a client-activated model, every client
that
> > creates a new object gets a dedicated server object. That object's
> lifetime
> > is governed by a lease, and the object will be disconnected from the
> clients
> > once its lease has expired. The only safe way to manage client-activated
> > objects is to use sponsors. All other options, such as global lease
> > properties or configuring individual objects' leases, are speculative at
> > best. Ultimately, only the client knows when it no longer needs the
> object.

The point being made in the excerpt above is that, for CAOs, it is
especially important that a client manage the object's lifetime by
registering a Sponsor in order to ensure the object does not get
disconnected by the server before the client is done with it. SAO's, on the
other hand, because they're intended to server multiple clients, generally
have their lifetimes controlled by the server. This is merely a statement of
best practices, not a requirement -- in the end, all remoted objects'
lifetimes follow the exact same set of rules.

Ken

Sam Santiago

8/2/2004 9:31:00 PM

I was fairly certain I read something about the client reference having some
impact on a CAO's lifetime, but I probably misunderstood. I'll have to dig
around for that again. If you have a CAO with a lifetime lease and no
sponsors registered how does the .NET remoting infrastructureand/or garbage
collection know when to reclaim that CAO?

I do not think lifetime management is the same for both CAOs and SAOs.
Here's an excerpt from the article I mentioned:

Managing the Lifetime of Remote .NET Objects with Leasing and Sponsorship by
Juval Lowy
http://msdn.microsoft.com/msdnmag/issues/03/12/LeaseManager/de...

"The only safe way to manage client-activated objects is to use sponsors.
All other options, such as global lease properties or configuring individual
objects' leases, are speculative at best."

--
_______________________________
Sam Santiago
ssantiago@n0spam-SoftiTechture.com
http://www.SoftiTe...
_______________________________
"Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
news:OottfJLeEHA.2376@tk2msftngp13.phx.gbl...
> See comments inline below...
>
> > > How you use a remote object does not alone determine whether it is a
CAO
> > or
> > > SAO. They are different and the key fundamental difference between an
> SAO
> > > and CAO is their lifetime management with leases. SAO lifetimes are
> > > controlled by the server, whereas CAO lifetimes are controlled by the
> > > client. If you attempt to use a CAO as a singleton that services all
> > > clients it's lifetime will be controlled by the first client that
> creates
> > > it. Even if you give this CAO a lifetime lease, it is not the same as
a
> > > lifetime lease on an SAO. As soon as the reference from the first
> client
> > > goes out of scope or is set to nothing your CAO singleton will be
> recycled
> > > on the server once it's lease expires. Below are some references to an
> > MSDN
> > > article and the .NET documentation that discusses this in more depth.
>
> For a CAO you said "it's lifetime will be controlled by the first client
> that creates it" and that its lifetime is somehow dependent upon whether
the
> client holds a reference to the object or not. None of that is correct.
The
> lifetime of every remoted object (SAO or CAO) is controlled exclusively by
> its lifetime lease and any sponsors registered for the object. It has
> nothing to do with whether a client's reference goes out of scope, is set
to
> null, the client shuts down, etc. When the lease expires (assuming there's
> no sponsor to renew it), that's it -- the object is disconnected from the
> remoting architecture by the server. In fact, this may happen while the
> client still has a reference to the object if the client has failed to
setup
> a sponsor, in which case, if the client attempts to use it, a "Request
> service not found" exception is thrown.
>
> The big difference between an SAO and a CAO is how the client's remoting
> framework generates the proxy for the object. For an SAO, the proxy is
> created by client with no info required from the server. For a CAO, the
> proxy is created from an ObjRef returned by the server which contains,
among
> other things, the URL for the object. The lifetime management of the two
> object types is identical.
>
> > > Client Activation
> > >
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconclientacti...
> > >
> > > Here's an excerpt:
> > >
> > > The client might even request an indefinite default lifetime,
> effectively
> > > preventing the remote object from ever being recycled until the server
> > > application domain is torn down. The difference between this and a
> > > server-activated indefinite lifetime is that an indefinite
> > server-activated
> > > object will serve all client requests for that type, whereas the
> > > client-activated instances serve only the client and the reference
that
> > was
> > > responsible for their creation.
>
> On the MSDN site, they generally use the term "client activation" to refer
> to remote objects created thru calls to either Activator.CreateObject() or
> using "new" when the type has been registered as a client-activated type.
In
> this case, it's not possible for two clients to share the same instance
> because it's the remoting framework which is instantiating the objects.
But,
> if you use a factory pattern and instantiate your own CAO's, there's
nothing
> to prevent you from returning the same CAO to multiple clients.
>
>
> > >
> > > Managing the Lifetime of Remote .NET Objects with Leasing and
> Sponsorship
> > by
> > > Juval Lowy
> > >
http://msdn.microsoft.com/msdnmag/issues/03/12/LeaseManager/de...
> > >
> > > Here's an excerpt:
> > >
> > > The case of the client-activated object is the one affected most by
the
> > > leasing mechanism. When using a client-activated model, every client
> that
> > > creates a new object gets a dedicated server object. That object's
> > lifetime
> > > is governed by a lease, and the object will be disconnected from the
> > clients
> > > once its lease has expired. The only safe way to manage
client-activated
> > > objects is to use sponsors. All other options, such as global lease
> > > properties or configuring individual objects' leases, are speculative
at
> > > best. Ultimately, only the client knows when it no longer needs the
> > object.
>
> The point being made in the excerpt above is that, for CAOs, it is
> especially important that a client manage the object's lifetime by
> registering a Sponsor in order to ensure the object does not get
> disconnected by the server before the client is done with it. SAO's, on
the
> other hand, because they're intended to server multiple clients, generally
> have their lifetimes controlled by the server. This is merely a statement
of
> best practices, not a requirement -- in the end, all remoted objects'
> lifetimes follow the exact same set of rules.
>
> Ken
>
>

Ken Kolda

8/2/2004 10:21:00 PM

If no sponsor is involved, then the remoted object gets disconnected from
the remoting framework when the lease expires. Once the remoting framework
disconnects the object, unless there is other server-side code holding a
reference to the object, it becomes eligible for GC.

Whether the client's still holding a reference to the object is
irrelevant -- the next time the client attempts to use it an exception will
be raised since the URI specified in the ObjRef will no longer be valid.
It's for this reason that the "only safe way to manage client-activated
objects" is to use sponsors -- if you don't use a client-side sponsor then
the object may disappear from under you without warning.

Ken

"Sam Santiago" <ssantiago@n0spam-SoftiTechture.com> wrote in message
news:uL2mPgNeEHA.2384@TK2MSFTNGP09.phx.gbl...
> I was fairly certain I read something about the client reference having
some
> impact on a CAO's lifetime, but I probably misunderstood. I'll have to dig
> around for that again. If you have a CAO with a lifetime lease and no
> sponsors registered how does the .NET remoting infrastructureand/or
garbage
> collection know when to reclaim that CAO?
>
> I do not think lifetime management is the same for both CAOs and SAOs.
> Here's an excerpt from the article I mentioned:
>
> Managing the Lifetime of Remote .NET Objects with Leasing and Sponsorship
by
> Juval Lowy
> http://msdn.microsoft.com/msdnmag/issues/03/12/LeaseManager/de...
>
> "The only safe way to manage client-activated objects is to use sponsors.
> All other options, such as global lease properties or configuring
individual
> objects' leases, are speculative at best."
>
> --
> _______________________________
> Sam Santiago
> ssantiago@n0spam-SoftiTechture.com
> http://www.SoftiTe...
> _______________________________
> "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
> news:OottfJLeEHA.2376@tk2msftngp13.phx.gbl...
> > See comments inline below...
> >
> > > > How you use a remote object does not alone determine whether it is a
> CAO
> > > or
> > > > SAO. They are different and the key fundamental difference between
an
> > SAO
> > > > and CAO is their lifetime management with leases. SAO lifetimes are
> > > > controlled by the server, whereas CAO lifetimes are controlled by
the
> > > > client. If you attempt to use a CAO as a singleton that services
all
> > > > clients it's lifetime will be controlled by the first client that
> > creates
> > > > it. Even if you give this CAO a lifetime lease, it is not the same
as
> a
> > > > lifetime lease on an SAO. As soon as the reference from the first
> > client
> > > > goes out of scope or is set to nothing your CAO singleton will be
> > recycled
> > > > on the server once it's lease expires. Below are some references to
an
> > > MSDN
> > > > article and the .NET documentation that discusses this in more
depth.
> >
> > For a CAO you said "it's lifetime will be controlled by the first client
> > that creates it" and that its lifetime is somehow dependent upon whether
> the
> > client holds a reference to the object or not. None of that is correct.
> The
> > lifetime of every remoted object (SAO or CAO) is controlled exclusively
by
> > its lifetime lease and any sponsors registered for the object. It has
> > nothing to do with whether a client's reference goes out of scope, is
set
> to
> > null, the client shuts down, etc. When the lease expires (assuming
there's
> > no sponsor to renew it), that's it -- the object is disconnected from
the
> > remoting architecture by the server. In fact, this may happen while the
> > client still has a reference to the object if the client has failed to
> setup
> > a sponsor, in which case, if the client attempts to use it, a "Request
> > service not found" exception is thrown.
> >
> > The big difference between an SAO and a CAO is how the client's remoting
> > framework generates the proxy for the object. For an SAO, the proxy is
> > created by client with no info required from the server. For a CAO, the
> > proxy is created from an ObjRef returned by the server which contains,
> among
> > other things, the URL for the object. The lifetime management of the two
> > object types is identical.
> >
> > > > Client Activation
> > > >
> > >
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconclientacti...
> > > >
> > > > Here's an excerpt:
> > > >
> > > > The client might even request an indefinite default lifetime,
> > effectively
> > > > preventing the remote object from ever being recycled until the
server
> > > > application domain is torn down. The difference between this and a
> > > > server-activated indefinite lifetime is that an indefinite
> > > server-activated
> > > > object will serve all client requests for that type, whereas the
> > > > client-activated instances serve only the client and the reference
> that
> > > was
> > > > responsible for their creation.
> >
> > On the MSDN site, they generally use the term "client activation" to
refer
> > to remote objects created thru calls to either Activator.CreateObject()
or
> > using "new" when the type has been registered as a client-activated
type.
> In
> > this case, it's not possible for two clients to share the same instance
> > because it's the remoting framework which is instantiating the objects.
> But,
> > if you use a factory pattern and instantiate your own CAO's, there's
> nothing
> > to prevent you from returning the same CAO to multiple clients.
> >
> >
> > > >
> > > > Managing the Lifetime of Remote .NET Objects with Leasing and
> > Sponsorship
> > > by
> > > > Juval Lowy
> > > >
> http://msdn.microsoft.com/msdnmag/issues/03/12/LeaseManager/de...
> > > >
> > > > Here's an excerpt:
> > > >
> > > > The case of the client-activated object is the one affected most by
> the
> > > > leasing mechanism. When using a client-activated model, every client
> > that
> > > > creates a new object gets a dedicated server object. That object's
> > > lifetime
> > > > is governed by a lease, and the object will be disconnected from the
> > > clients
> > > > once its lease has expired. The only safe way to manage
> client-activated
> > > > objects is to use sponsors. All other options, such as global lease
> > > > properties or configuring individual objects' leases, are
speculative
> at
> > > > best. Ultimately, only the client knows when it no longer needs the
> > > object.
> >
> > The point being made in the excerpt above is that, for CAOs, it is
> > especially important that a client manage the object's lifetime by
> > registering a Sponsor in order to ensure the object does not get
> > disconnected by the server before the client is done with it. SAO's, on
> the
> > other hand, because they're intended to server multiple clients,
generally
> > have their lifetimes controlled by the server. This is merely a
statement
> of
> > best practices, not a requirement -- in the end, all remoted objects'
> > lifetimes follow the exact same set of rules.
> >
> > Ken
> >
> >
>
>

Sunny

8/3/2004 12:07:00 AM

Very well defined Ken. This, and the other post to the other thread
explained much better what I had in mind.

Actually, if we go simplifying the things, SAO and CAO are just
"syntactic sugar" for how and when the objects are created, how and when
the ObjRef's are created, and how and when they are passed back to the
client. Using the RegisterWellKnownxxx just makes the thinks easy, but
most of it's work can be done as I do in the sample I attached to the
other thread.

Of course, this example realy oversimplified, but it shows the idea. If
you add to this example the result of the work of xx thousand peopledays
in MS for more than 5 years ... ummm, here is the remoting :)

2 c

Cheers
Sunny

Sam Santiago

8/3/2004 12:51:00 AM

CAOs with an indefinite lifeteam lease will hang around until the app domain
is recycled. So if you are using CAOs you probably do not want to use
indefinite leases unless you are implementing a singleton, otherwise you
could potentially have many objects in the remote server app domain that are
hanging around consuming resources.

Check out this link:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconclientacti...

"The client might even request an indefinite default lifetime, effectively
preventing the remote object from ever being recycled until the server
application domain is torn down."

--
_______________________________
Sam Santiago
ssantiago@n0spam-SoftiTechture.com
http://www.SoftiTe...
_______________________________
"Sam Santiago" <ssantiago@n0spam-SoftiTechture.com> wrote in message
news:uL2mPgNeEHA.2384@TK2MSFTNGP09.phx.gbl...
> I was fairly certain I read something about the client reference having
some
> impact on a CAO's lifetime, but I probably misunderstood. I'll have to dig
> around for that again. If you have a CAO with a lifetime lease and no
> sponsors registered how does the .NET remoting infrastructureand/or
garbage
> collection know when to reclaim that CAO?
>
> I do not think lifetime management is the same for both CAOs and SAOs.
> Here's an excerpt from the article I mentioned:
>
> Managing the Lifetime of Remote .NET Objects with Leasing and Sponsorship
by
> Juval Lowy
> http://msdn.microsoft.com/msdnmag/issues/03/12/LeaseManager/de...
>
> "The only safe way to manage client-activated objects is to use sponsors.
> All other options, such as global lease properties or configuring
individual
> objects' leases, are speculative at best."
>
> --
> _______________________________
> Sam Santiago
> ssantiago@n0spam-SoftiTechture.com
> http://www.SoftiTe...
> _______________________________
> "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
> news:OottfJLeEHA.2376@tk2msftngp13.phx.gbl...
> > See comments inline below...
> >
> > > > How you use a remote object does not alone determine whether it is a
> CAO
> > > or
> > > > SAO. They are different and the key fundamental difference between
an
> > SAO
> > > > and CAO is their lifetime management with leases. SAO lifetimes are
> > > > controlled by the server, whereas CAO lifetimes are controlled by
the
> > > > client. If you attempt to use a CAO as a singleton that services
all
> > > > clients it's lifetime will be controlled by the first client that
> > creates
> > > > it. Even if you give this CAO a lifetime lease, it is not the same
as
> a
> > > > lifetime lease on an SAO. As soon as the reference from the first
> > client
> > > > goes out of scope or is set to nothing your CAO singleton will be
> > recycled
> > > > on the server once it's lease expires. Below are some references to
an
> > > MSDN
> > > > article and the .NET documentation that discusses this in more
depth.
> >
> > For a CAO you said "it's lifetime will be controlled by the first client
> > that creates it" and that its lifetime is somehow dependent upon whether
> the
> > client holds a reference to the object or not. None of that is correct.
> The
> > lifetime of every remoted object (SAO or CAO) is controlled exclusively
by
> > its lifetime lease and any sponsors registered for the object. It has
> > nothing to do with whether a client's reference goes out of scope, is
set
> to
> > null, the client shuts down, etc. When the lease expires (assuming
there's
> > no sponsor to renew it), that's it -- the object is disconnected from
the
> > remoting architecture by the server. In fact, this may happen while the
> > client still has a reference to the object if the client has failed to
> setup
> > a sponsor, in which case, if the client attempts to use it, a "Request
> > service not found" exception is thrown.
> >
> > The big difference between an SAO and a CAO is how the client's remoting
> > framework generates the proxy for the object. For an SAO, the proxy is
> > created by client with no info required from the server. For a CAO, the
> > proxy is created from an ObjRef returned by the server which contains,
> among
> > other things, the URL for the object. The lifetime management of the two
> > object types is identical.
> >
> > > > Client Activation
> > > >
> > >
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconclientacti...
> > > >
> > > > Here's an excerpt:
> > > >
> > > > The client might even request an indefinite default lifetime,
> > effectively
> > > > preventing the remote object from ever being recycled until the
server
> > > > application domain is torn down. The difference between this and a
> > > > server-activated indefinite lifetime is that an indefinite
> > > server-activated
> > > > object will serve all client requests for that type, whereas the
> > > > client-activated instances serve only the client and the reference
> that
> > > was
> > > > responsible for their creation.
> >
> > On the MSDN site, they generally use the term "client activation" to
refer
> > to remote objects created thru calls to either Activator.CreateObject()
or
> > using "new" when the type has been registered as a client-activated
type.
> In
> > this case, it's not possible for two clients to share the same instance
> > because it's the remoting framework which is instantiating the objects.
> But,
> > if you use a factory pattern and instantiate your own CAO's, there's
> nothing
> > to prevent you from returning the same CAO to multiple clients.
> >
> >
> > > >
> > > > Managing the Lifetime of Remote .NET Objects with Leasing and
> > Sponsorship
> > > by
> > > > Juval Lowy
> > > >
> http://msdn.microsoft.com/msdnmag/issues/03/12/LeaseManager/de...
> > > >
> > > > Here's an excerpt:
> > > >
> > > > The case of the client-activated object is the one affected most by
> the
> > > > leasing mechanism. When using a client-activated model, every client
> > that
> > > > creates a new object gets a dedicated server object. That object's
> > > lifetime
> > > > is governed by a lease, and the object will be disconnected from the
> > > clients
> > > > once its lease has expired. The only safe way to manage
> client-activated
> > > > objects is to use sponsors. All other options, such as global lease
> > > > properties or configuring individual objects' leases, are
speculative
> at
> > > > best. Ultimately, only the client knows when it no longer needs the
> > > object.
> >
> > The point being made in the excerpt above is that, for CAOs, it is
> > especially important that a client manage the object's lifetime by
> > registering a Sponsor in order to ensure the object does not get
> > disconnected by the server before the client is done with it. SAO's, on
> the
> > other hand, because they're intended to server multiple clients,
generally
> > have their lifetimes controlled by the server. This is merely a
statement
> of
> > best practices, not a requirement -- in the end, all remoted objects'
> > lifetimes follow the exact same set of rules.
> >
> > Ken
> >
> >
>
>

microsoft.public.dotnet.framework.remoting

Re: Remoting Singleton with strongly typed collection in it

Sam Santiago

Terry

Sam Santiago

Sunny

Sam Santiago

Sam Santiago

Ken Kolda

Sam Santiago

Ken Kolda

Sunny

Sam Santiago

x Login to ForumsZone