>MTS is entirely stateless so the only time you have the object is when you reference. If you had two properties on this object called prop1 and prop2 and you assigned values to them like ox.prop1 = 1 and ox.prop2 =2. There is no guarantee that the properties you set will belong to the same object in the MTS pool. Between setting prop1 and setting prop2 you make be actually referencing a different object. This is not necessarily a bad thing but needs to be known thing. SetComplete will then mark your transaction as complete and do the stuff it needs to do to see that it is completed. This does not mean you have specific instances of objects for the duration of your transaction.
>
>What this implies is you should not set properties but pass all required values as parameters to a method. This certainly becomes less intuitive and perhaps less manageable but that is for each of us to decide.

I still disagree. From my personal testing and reading of MTS SetComplete() not only commits a transaction but it deactivates you object. Here is a piece from the MTS help file.

When is an object deactivated?

An MTS object is deactivated when any of the following occurs:

· The object requests deactivation.

An object can request deactivation by using the IObjectContext interface. You can use the SetComplete method to indicate that the object has successfully completed its work and that the internal object state doesn't need to be retained for the next call from the client. Similarly, SetAbort indicates that the object cannot successfully complete its work and that its state does not need to be retained.

You can develop stateless objects by using MTS objects that deactivate on return from every method.

· A transaction is committed or aborted.

MTS does not allow an object to maintain private state that it acquired during a transaction. When an object's transaction is committed or aborted, the object is deactivated. Of these deactivated objects, the only ones that can continue to exist are the ones that have references from clients outside the transaction. Subsequent calls to these objects reactivate them and cause them to execute in the next transaction.

· The last client releases the object.

This occurrence is listed here for completeness. The object is deactivated and never reactivated. The object's context is also released.

How are objects deactivated?

MTS deactivates an object by releasing all its references to the object. This causes properly developed components to destroy the object; this feature also requires the component to follow the MTS reference passing rules (see Passing Object References) and the COM reference counting rules.

Note MTS writes an Informational message to the event log when objects that do not report their reference count are deactivated.

Application components are responsible for releasing object resources on deactivation. This includes:

· Resources that are allocated with MTS resource dispensers, such as ODBC database connections.
· All other resources, including references to other objects (including MTS objects and context objects) and memory held by any instances of the component, such as using delete this in C++).