Stateless Object

[AlessandroR]

Hi all,
maybe my question is stupid, but I really need to know
when an Object is to be considered "stateless".
I see everywhere that Object to be pooled and to be avtivated JIT must be stateless, but what does it mean exaclty?
I read that an Object to be stateless should have no attributes, but this means that it's not an Object but a set of functions ... this means that I could throw away all the OOP concepts ... and I don't like this idea.
I also read (but I hope this is not real) that code like this:

Set X = CreateObject("MyObj&quot
X.MethodA(); 'This method sets the value of attribute "A"

... other stuff

Y = X.A;

...


should not work because JIT and POOLING should give object
X to other clients that may change the object so when I read attribute A of X (if X is a transaction Object in MTS) I could not get it as I previuosly set ... this seems to be orrible!!!

(I used VB syntax, but I'm interested in MTS concepts ... I know VB limits about pooling, in fact I will use C#)
Thanks for any explanations you have for me.
Alessandro

 

[nomi2000]

Dear Alessandro
well there are some misconception about the stateless behavoiur of MTS object..Remebere its a good practice to design the MTS components to be stateless but its not necessary..okay now i would explain why its good for a MTS object should be stateless
---Clients should acquire and hold onto interface pointers, even for COM objects that they won't use until much later. Getting a reference to an object can be costly, but if the object is stateless, holding it is free with MTS.

--Imagine a Visual Basic client that's setting various properties in an MTS object. The client may think it's working with an ordinary COM object—all the language syntax is exactly the same. But suppose that after setting several properties in the object the client invokes a method in the MTS object that calls SetComplete. If this happens, the object will be deactivated, as described above, losing all of its state. If the client isn't aware this has occurred, it may be very surprised. The client might, for example, attempt to get the value of some property it has just set in this object, only to discover that that value has been reset to its default. If the client doesn't know which methods in an object's interfaces call SetComplete, it might be confused by the object's behavior. This in turn implies something else: the client must know that this is an MTS object, not just a vanilla COM object.

i hope u undestand what it means
i know MTS compoents written in VB r not the hardcore ones but still they can be used quite effiecintly as far as my exp is concerned it works prefecto if designeed carefully...
well yes the compoentne built with C# are more hardcore and robust but u see it need a lot of effort to design a very good component in C# ,well according to me the bottom line is if someone is good at VB compoenent design then he should go for it but if he is good in C# then he should go for it,simple
hope it help u
Regards
Nouman
Senior Software Engineer