Re: remoting options

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Man, you were bored werent you :). Super cool explanation. So moral of the
story is to use Single Call SAO correct? Can I pass in custom objects as
parameters to a method? e.g.:

Client Invocation:

Dim db as new DBClass
db.savecustomer(cust)

thanks,
PR

P.S. Are there any code samples available on MSDN on Single Call SAO? I am a
VB developer.

thanks

"peter" <apvx95@xxxxxxxxxxxxx> wrote in message
news:42ac82aa$0$290$cc9e4d1f@xxxxxxxxxxxxxxxxxxxxxx
> param@xxxxxxxxxxxxxxxx wrote:
>> Peter, you mention stateful vs stateless objects. Can you give me an
>> example of each? What is the difference?
>>
> OK, you caught me on a boring day.
>
> If your object holds state (has state variables/fields) then it is
> stateful. If it doesn't, it isn't: it's stateless.
>
> Actually it's a bit more complex than that. To understand why, you need
> to understand the different types of remote object in the .NET bestiary.
>
> There are two main types: server activated and client activated.
>
> Server activated objects (SAOs) come in two flavours:
> * singleton
> * single call
>
> Neither of these may have constructors other than a default constructor
> (actually, they can have them, but there is no way of calling them); so
> you could initialise state variables in the default constructor if you
> wanted to. However, doing so could cause problems as you will see below.
>
> A single call SAO is re-created each time a method is called on it, and
> destroyed as soon as the call returns. So despite (possibly) using the
> 'new' operator to create it - on the client side - what actually happens
> when you make calls on the remote single call SAO is that for each method
> call the client makes the constructor followed by the required method, is
> run on the server side. In this scenario the only state the object can
> have is any state set up in the constructor - effectively turning the
> state variables/fields into constants.
>
> A singleton SAO is a little different. It is created the first time a
> method is called on it, and persists for a length of time determined by
> its lifetime lease. This means that you can change its state - if it has
> the necessary state variables/fields. However, the singleton object
> guarantees that the server will only create one instance of the object at
> any time. This means that the state can be changed not only by you, but
> also by anyone else connecting to it. Further, once the lease runs out,
> the object is destroyed and the state is lost anyway. Both these
> scenarios would be disastrous for any program relying on the saved state
> of the object.
>
> So, in summary, for SAOs, it's fine to initialise single call SAOs, but
> that's all you should do. Singleton SAOs should be considered completely
> stateless unless you want to spend a lot of time chasing weird behaviour.
>
> Actually, since it only takes a one-word change to a config file to change
> an object from being single call to singleton, I'd treat single call
> objects as stateless as well, if I were you. I do.
>
> I have yet to meet a situation where I really, really, really could not
> change things around to make my remote objects stateless. That's not to
> say that I haven't sometimes made them stateless when the amount of work
> necessary to make them so seemed excessive.
>
> Client activated objects (CAOs) can have as many constructors as you
> like - and you can call them using the factory pattern and direct
> remoting. CAOs are associated with a 'session', so any state you save
> belongs to the session and can't be screwed up by anyone else. You need
> CAOs if you need stateful remote objects.
>
> CAOs are created when the client calls 'new', and persist for the length
> of their lease. The lease length can be configured, however, and leases
> can be renewed if necessary, so you don't have to lose any state you want
> to preserve.
>
> I found CAOs much more difficult than SAOs - and usually unnecessary, to
> be honest. They are fun, though.
>
> HTH
>
> Peter


.