[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Singleton - SingleCall confusion

sbparsons

11/1/2004 6:53:00 AM

I have an SAO registered as a Singleton (tcp) and a client that uses an MBR
'shim' to marshal the events between the two. The client spawns a seperate
thread to create and manage the remote server object. The client creates the
remote proxy, populates a few parameters and calls a function to do some
reasonably long processing. This works well when run over a LAN, including
the event marshalling.

However, when I attempt to change the server type to SingleCall the
application fails on the server. I have created a shared object counter on
the server and each instantiation of the remote server object increments this
variable. I have noticed this variable incrementing for each property call
that I make from the client on the proxy. It appears to be creating a new
object each time I populate the proxy object with a parameter. Each new
object obviously now does not have the parameters that were passed
previously, so is failing when attempting to reference them later in the code
(Null reference exception)

Is there something basic I'm missing? My gut feel would be that the client
would maintain a reference to a particular SingleCall remote object and not
lose reference to it on each property call... but that sounds more like CAO
to me.
7 Answers

CT

11/1/2004 7:57:00 AM

0

The SingleCall object is just that, a single call as it is stateless so you
loose everything between calls.

--
Carsten Thomsen
Enterprise Development with VS .NET, UML, and MSF
http://www.apress.com/book/bookDisplay.ht...
"sbparsons" <sbparsons@discussions.microsoft.com> wrote in message
news:EE3201AB-B0B0-4BC4-94E6-BD1073957FAA@microsoft.com...
>I have an SAO registered as a Singleton (tcp) and a client that uses an MBR
> 'shim' to marshal the events between the two. The client spawns a seperate
> thread to create and manage the remote server object. The client creates
> the
> remote proxy, populates a few parameters and calls a function to do some
> reasonably long processing. This works well when run over a LAN, including
> the event marshalling.
>
> However, when I attempt to change the server type to SingleCall the
> application fails on the server. I have created a shared object counter on
> the server and each instantiation of the remote server object increments
> this
> variable. I have noticed this variable incrementing for each property call
> that I make from the client on the proxy. It appears to be creating a new
> object each time I populate the proxy object with a parameter. Each new
> object obviously now does not have the parameters that were passed
> previously, so is failing when attempting to reference them later in the
> code
> (Null reference exception)
>
> Is there something basic I'm missing? My gut feel would be that the client
> would maintain a reference to a particular SingleCall remote object and
> not
> lose reference to it on each property call... but that sounds more like
> CAO
> to me.


sbparsons

11/1/2004 10:43:00 AM

0

So would the best practice here be to create a serializable structure to
hold the properties and pass that in as a single call?

"CT" wrote:

> The SingleCall object is just that, a single call as it is stateless so you
> loose everything between calls.
>
> --
> Carsten Thomsen
> Enterprise Development with VS .NET, UML, and MSF
> http://www.apress.com/book/bookDisplay.ht...
> "sbparsons" <sbparsons@discussions.microsoft.com> wrote in message
> news:EE3201AB-B0B0-4BC4-94E6-BD1073957FAA@microsoft.com...
> >I have an SAO registered as a Singleton (tcp) and a client that uses an MBR
> > 'shim' to marshal the events between the two. The client spawns a seperate
> > thread to create and manage the remote server object. The client creates
> > the
> > remote proxy, populates a few parameters and calls a function to do some
> > reasonably long processing. This works well when run over a LAN, including
> > the event marshalling.
> >
> > However, when I attempt to change the server type to SingleCall the
> > application fails on the server. I have created a shared object counter on
> > the server and each instantiation of the remote server object increments
> > this
> > variable. I have noticed this variable incrementing for each property call
> > that I make from the client on the proxy. It appears to be creating a new
> > object each time I populate the proxy object with a parameter. Each new
> > object obviously now does not have the parameters that were passed
> > previously, so is failing when attempting to reference them later in the
> > code
> > (Null reference exception)
> >
> > Is there something basic I'm missing? My gut feel would be that the client
> > would maintain a reference to a particular SingleCall remote object and
> > not
> > lose reference to it on each property call... but that sounds more like
> > CAO
> > to me.
>
>
>

CT

11/1/2004 11:45:00 AM

0

There are various options available, but if you want state why not go for a
Singleton or CAO?

--
Carsten Thomsen
Enterprise Development with VS .NET, UML, and MSF
http://www.apress.com/book/bookDisplay.ht...
"sbparsons" <sbparsons@discussions.microsoft.com> wrote in message
news:2E326C90-5A09-4619-9B5C-8FF78ECA0316@microsoft.com...
> So would the best practice here be to create a serializable structure to
> hold the properties and pass that in as a single call?
>
> "CT" wrote:
>
>> The SingleCall object is just that, a single call as it is stateless so
>> you
>> loose everything between calls.
>>
>> --
>> Carsten Thomsen
>> Enterprise Development with VS .NET, UML, and MSF
>> http://www.apress.com/book/bookDisplay.ht...
>> "sbparsons" <sbparsons@discussions.microsoft.com> wrote in message
>> news:EE3201AB-B0B0-4BC4-94E6-BD1073957FAA@microsoft.com...
>> >I have an SAO registered as a Singleton (tcp) and a client that uses an
>> >MBR
>> > 'shim' to marshal the events between the two. The client spawns a
>> > seperate
>> > thread to create and manage the remote server object. The client
>> > creates
>> > the
>> > remote proxy, populates a few parameters and calls a function to do
>> > some
>> > reasonably long processing. This works well when run over a LAN,
>> > including
>> > the event marshalling.
>> >
>> > However, when I attempt to change the server type to SingleCall the
>> > application fails on the server. I have created a shared object counter
>> > on
>> > the server and each instantiation of the remote server object
>> > increments
>> > this
>> > variable. I have noticed this variable incrementing for each property
>> > call
>> > that I make from the client on the proxy. It appears to be creating a
>> > new
>> > object each time I populate the proxy object with a parameter. Each new
>> > object obviously now does not have the parameters that were passed
>> > previously, so is failing when attempting to reference them later in
>> > the
>> > code
>> > (Null reference exception)
>> >
>> > Is there something basic I'm missing? My gut feel would be that the
>> > client
>> > would maintain a reference to a particular SingleCall remote object and
>> > not
>> > lose reference to it on each property call... but that sounds more like
>> > CAO
>> > to me.
>>
>>
>>


sbparsons

11/2/2004 4:58:00 AM

0

Hi CT

Another quick question : If I have a SingleCall and want to stop it's
execution, is it possible from the client (ie if the cancel button is
clicked)? I can obviously abort the client worker thread but would that in
turn abort the remote thread?

Thanks for the answers so far.

"CT" wrote:

> There are various options available, but if you want state why not go for a
> Singleton or CAO?
>
> --
> Carsten Thomsen
> Enterprise Development with VS .NET, UML, and MSF
> http://www.apress.com/book/bookDisplay.ht...
> "sbparsons" <sbparsons@discussions.microsoft.com> wrote in message
> news:2E326C90-5A09-4619-9B5C-8FF78ECA0316@microsoft.com...
> > So would the best practice here be to create a serializable structure to
> > hold the properties and pass that in as a single call?
> >
> > "CT" wrote:
> >
> >> The SingleCall object is just that, a single call as it is stateless so
> >> you
> >> loose everything between calls.
> >>
> >> --
> >> Carsten Thomsen
> >> Enterprise Development with VS .NET, UML, and MSF
> >> http://www.apress.com/book/bookDisplay.ht...
> >> "sbparsons" <sbparsons@discussions.microsoft.com> wrote in message
> >> news:EE3201AB-B0B0-4BC4-94E6-BD1073957FAA@microsoft.com...
> >> >I have an SAO registered as a Singleton (tcp) and a client that uses an
> >> >MBR
> >> > 'shim' to marshal the events between the two. The client spawns a
> >> > seperate
> >> > thread to create and manage the remote server object. The client
> >> > creates
> >> > the
> >> > remote proxy, populates a few parameters and calls a function to do
> >> > some
> >> > reasonably long processing. This works well when run over a LAN,
> >> > including
> >> > the event marshalling.
> >> >
> >> > However, when I attempt to change the server type to SingleCall the
> >> > application fails on the server. I have created a shared object counter
> >> > on
> >> > the server and each instantiation of the remote server object
> >> > increments
> >> > this
> >> > variable. I have noticed this variable incrementing for each property
> >> > call
> >> > that I make from the client on the proxy. It appears to be creating a
> >> > new
> >> > object each time I populate the proxy object with a parameter. Each new
> >> > object obviously now does not have the parameters that were passed
> >> > previously, so is failing when attempting to reference them later in
> >> > the
> >> > code
> >> > (Null reference exception)
> >> >
> >> > Is there something basic I'm missing? My gut feel would be that the
> >> > client
> >> > would maintain a reference to a particular SingleCall remote object and
> >> > not
> >> > lose reference to it on each property call... but that sounds more like
> >> > CAO
> >> > to me.
> >>
> >>
> >>
>
>
>

Ken Kolda

11/2/2004 4:23:00 PM

0

Aborting the client thread will not cause the server thread to abort. If you
want to be able to cancel your object's activity, you'll need to build
something more sophisticated. For example, when you invoke the method which
you may want to cancel later, have it return a CAO which has a Cancel()
method on it. The client can then invoke the Cancel() method to cancel the
server processing.

On the server side, when Cancel() is called, the CAO sets a flag on the
object doing the processing which tells it to stop. You do not want to stop
the process by calling Thread.Abort() -- this is not the appropriate way to
gracefully terminate a thread and may result in you losing a thread pool
thread irrevocably (not sure whether the thread pool will start up a new
thread). Your long-running process should periodically check for the state
of this "cancel flag" and gracefully abort its processing.

Ken


"sbparsons" <sbparsons@discussions.microsoft.com> wrote in message
news:A95DDE2A-A7BA-469A-A8F8-CE36473BAAE4@microsoft.com...
> Hi CT
>
> Another quick question : If I have a SingleCall and want to stop it's
> execution, is it possible from the client (ie if the cancel button is
> clicked)? I can obviously abort the client worker thread but would that in
> turn abort the remote thread?
>
> Thanks for the answers so far.
>
> "CT" wrote:
>
> > There are various options available, but if you want state why not go
for a
> > Singleton or CAO?
> >
> > --
> > Carsten Thomsen
> > Enterprise Development with VS .NET, UML, and MSF
> > http://www.apress.com/book/bookDisplay.ht...
> > "sbparsons" <sbparsons@discussions.microsoft.com> wrote in message
> > news:2E326C90-5A09-4619-9B5C-8FF78ECA0316@microsoft.com...
> > > So would the best practice here be to create a serializable structure
to
> > > hold the properties and pass that in as a single call?
> > >
> > > "CT" wrote:
> > >
> > >> The SingleCall object is just that, a single call as it is stateless
so
> > >> you
> > >> loose everything between calls.
> > >>
> > >> --
> > >> Carsten Thomsen
> > >> Enterprise Development with VS .NET, UML, and MSF
> > >> http://www.apress.com/book/bookDisplay.ht...
> > >> "sbparsons" <sbparsons@discussions.microsoft.com> wrote in message
> > >> news:EE3201AB-B0B0-4BC4-94E6-BD1073957FAA@microsoft.com...
> > >> >I have an SAO registered as a Singleton (tcp) and a client that uses
an
> > >> >MBR
> > >> > 'shim' to marshal the events between the two. The client spawns a
> > >> > seperate
> > >> > thread to create and manage the remote server object. The client
> > >> > creates
> > >> > the
> > >> > remote proxy, populates a few parameters and calls a function to do
> > >> > some
> > >> > reasonably long processing. This works well when run over a LAN,
> > >> > including
> > >> > the event marshalling.
> > >> >
> > >> > However, when I attempt to change the server type to SingleCall the
> > >> > application fails on the server. I have created a shared object
counter
> > >> > on
> > >> > the server and each instantiation of the remote server object
> > >> > increments
> > >> > this
> > >> > variable. I have noticed this variable incrementing for each
property
> > >> > call
> > >> > that I make from the client on the proxy. It appears to be creating
a
> > >> > new
> > >> > object each time I populate the proxy object with a parameter. Each
new
> > >> > object obviously now does not have the parameters that were passed
> > >> > previously, so is failing when attempting to reference them later
in
> > >> > the
> > >> > code
> > >> > (Null reference exception)
> > >> >
> > >> > Is there something basic I'm missing? My gut feel would be that the
> > >> > client
> > >> > would maintain a reference to a particular SingleCall remote object
and
> > >> > not
> > >> > lose reference to it on each property call... but that sounds more
like
> > >> > CAO
> > >> > to me.
> > >>
> > >>
> > >>
> >
> >
> >

sbparsons

11/3/2004 2:13:00 AM

0

I like your CAO idea, Ken, but am having a few problems.
I have defined a common 'Cancel' object alongside my server interface so
that both client and server have access to the type. On the server I have
instantiated a new 'Cancel' object. I have passed in a delegate to a server
procedure that sets a cancel flag - this delegate will be invoked by the
client during the cancel event.

With a singlecall object, though, how can I pass this object back to the
client? The client obviously only makes one call to the server object which
is the call to the lengthy procedure - so no return value until the end of
this procedure.

At the end of the day, I can use a singleton to preserve state but may
discover a few threadsafe worries - they might be easier to overcome though...
My original query (see start of this 'thread') was actually trying to gauge
the benefits of SingleCall over Singleton so any input there would be great.

Thanks for your help.
Sean

Ken Kolda

11/3/2004 4:15:00 PM

0

For the issue of the Cancel object, you would need to have your server
object spawn a new thread to perform the actual processing. The function
would then return the Cancel object to the client.

As for Singleton vs. SingleCall, this really depends on your needs.
Actually, based on what you've said, a CAO may be more appropriate than
either of these SAO types. Each client would create its own object instance
on the server and invoke it to start the process. Using this technique you
could even avoid having a Cancel object altogether -- there would simply be
a Cancel() method on the CAO type which would flag the thread which is doing
the processing.

Ken


"sbparsons" <sbparsons@discussions.microsoft.com> wrote in message
news:2ED9B13F-650E-484C-A47B-B34222E928CF@microsoft.com...
> I like your CAO idea, Ken, but am having a few problems.
> I have defined a common 'Cancel' object alongside my server interface so
> that both client and server have access to the type. On the server I have
> instantiated a new 'Cancel' object. I have passed in a delegate to a
server
> procedure that sets a cancel flag - this delegate will be invoked by the
> client during the cancel event.
>
> With a singlecall object, though, how can I pass this object back to the
> client? The client obviously only makes one call to the server object
which
> is the call to the lengthy procedure - so no return value until the end of
> this procedure.
>
> At the end of the day, I can use a singleton to preserve state but may
> discover a few threadsafe worries - they might be easier to overcome
though...
> My original query (see start of this 'thread') was actually trying to
gauge
> the benefits of SingleCall over Singleton so any input there would be
great.
>
> Thanks for your help.
> Sean
>