MTS Sins

Results 1 to 3 of 3

Thread: MTS Sins

  1. #1
    SPG Guest

    Default MTS Sins

    Just wondering which of these options is more fundamentally wrong in an MTS distributed system with COM coming from VB:<BR><BR>1) Repeatedly called [from a For loop] DCOM function has 4 byRef parameters going back and forth over the network. (This is hard on the marshalling, they have to be passed as variants [performance no-no; .NET incompatibility], and it fundamentally scares me. It does, however, make the remote object perfectly stateless which makes a lot of COM-groupies happy.)<BR><BR>2) Remote object has three properties that the local object picks up immediately after the repeated calling is completed but while the same instance of the object is still in use. (The catch is that I&#039;ve seen and heard people whining about how objects have to be completely stateless or MTS gets really stupid and crashes. I&#039;ve never seen this behavior, I&#039;ve never seen a document that suggests that two-way marshalling of variants scales better.)<BR><BR>If anybody has any information on the merits/flaws of pushing state back and forth on DCOM as opposed to simply asking for some collected information when the function calls are done (it&#039;s all inside of one local method either way), I&#039;d appreciate it.<BR><BR>SPG

  2. #2
    Paul K Guest

    Default RE: MTS Sins

    SPG:<BR><BR>I&#039;d agree with you that the first option (the repeated by ref calls using DCOM) would be very inefficient and, to my mind, not a wise choice. I&#039;ve done a fair amount of MTS VB development, and personally have no problem with a bit o&#039; state, particularly if a transaction is pending. As Ted Pattison points out (he has a very good book) -- some would argue this -- the main benefit of MTS is NOT that it&#039;s "stateless," but that you can use it to ensure completely atomic transactions (the transactional part of MTS).<BR><BR>Obviously he adheres to the stateless model, but not to extremes. What about the idea of collecting those four byrefs first, in the client, and then passing them all together in one call? You could also provide a single method, GetAllOfThem, in addition to your individual properties.<BR><BR>The only caveat I&#039;d add to this is, How long is your client holding on to the MTS object? If it&#039;s simply for the life of a few calls, then I&#039;d say no problem at all. But if it&#039;s being held while a user has to interact and make choices, then I&#039;d say you should get your data, destroy the object, and then create a new one if and when you need it again.<BR><BR>Hope that helps,<BR>Paul K

  3. #3
    Join Date
    Dec 1969

    Default RE: MTS Sins

    Everything that I&#039;ve read indicates to me that people get way too het up about "statelessness" in MTS objects. It&#039;s perfectly permissible to maintain some state in an object, as long as it&#039;s within the scope of a single transaction.<BR><BR>Also, I&#039;ve never heard of MTS crashing because of object state - the worst that can happen is that your object doesn&#039;t have the state you thought it did (becasue it&#039;s not the same object).<BR><BR>Sounds to me like your whiners know less than they think they do. Or is it that I know less than I think I do...?<BR><BR>Dunc

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts