Mts Objects Can Be Stateful

MTS objects can be stateful. What they can't do is maintain state across transaction boundaries. This is to maintain the consistency of transactions. In particular, this means you don't have to deactivate objects between every method call as some Microsoft publications might have you believe. -- FabianLeGayBrereton

Actually, they can maintain state across transaction boundaries. They store it in a database instead of in RAM, but it is still their state. -- YonatSharon

I guess it depends on your definition of StatelessObject and StatefulObject. Microsoft appears to intend stateless to mean "calls SetComplete? at the end of every method" -- FabianLeGayBrereton

What bothers me is that MTS objects lose state and identity at transaction boundaries. So MTS objects can't restore their state from the database without help from the client:

At the start of each transaction, the client must inform each object of its identity. Like, if an MTS object is to represent a customer, than the client must pass the key (say, customer id) to the MTS object, so it will know which customer record to read.

And, since network round-trips between client and MTS server are expensive, you should probably minimize them, so the fact that an object can maintain state within a transaction is largely useless.

If you code MTS COM "objects" as recommended by Microsoft, you minimize method calls and lose state between transactions. I would no longer call these "objects," as they have no state. Such "stateless objects" are just namespaces - convenient collections of procedural functions. -- JeffGrigg

In another DnaVsOo, someone said: [In] objects supporting transactions the state will be destroyed between transactions in order to make sure you aren't reusing the state from a previous call (which would, naturally, destroy and ACIDity the transaction had). [...] you could end up using the data that has been 'left behind' by the first call which gives unspecified results.

Let's say we have a value sitting on a users screen that was the result of some transaction. Isn't it possible that the ACIDity of that transaction can be compromised by an action the user takes?

If we can't have stateful objects, why don't we have a problem with stateful users? -- FabianLeGayBrereton

Users are stateful, so you have to include them in the transaction. This is usually done with "optimistic locking"; by checking the database record before doing the update, to make sure it was not changed by someone else. If it was changed by someone else, while this user was "thinking," then this user's transaction is rolled back, and they'll have to refresh the screen or somehow resolve the conflict. -- JeffGrigg

If we have to worry about optimistic locking to include users in the transaction aren't we giving up the benefits of MTSs transaction model? -- FabianLeGayBrereton

No, not at all - these are two independent issues:

"Optimistic locking" for user changes is quite independent of the server's locking strategy. (You could tie the two, holding a server lock for the entire duration of the user transaction, including user "think time," but this would be a very bad idea.)

Example:

Say you want to change an employee's address from "123 This Street" to "321 This Street" and double their salary. A typical SQL Server strategy would be to select employee name, address, salary, and the record's update timestamp from the employee record, and display them (minus the timestamp) to the user. The user examines the current address and salary, updates them, and presses the "save" button. The server code then starts a SQL Server transaction, updates the two columns *IF* the timestamp currently on the server's record matches the timestamp we read above, and commits ("set complete" in MTS).

At commit time, MTS discards the server object that did the "set complete" call, because MTS won't tell the object if its transaction actually committed or was rolled back. Even though the object did "set complete," there's no way it can know if the address is now 321, or if it rolled back to 123 - unless we read from the database, to check it. -- JeffGrigg

Obviously, MTS objects can be stateful , if you Marshal the state between the components and DB for each transaction or at the end of a nested transaction. Similarly, you may pass it as a parameter for each client-server components transaction interaction. But the whole point is that it rests with the developer to write all this management code and then maintaining it explicitly. With EJB, you get the advantage of getting your time saved from this plumbing, and this is the whole point of having a middleware.

-- mumtaz

See MicrosoftTransactionServer, ComComponent

CategoryMicrosoft CategoryComponents