From: Jim.Johnson@software-exploration.nospam.com Sent: Wednesday, August 23, 2000 10:25 PM To: Info-VAX@Mvb.Saic.Com Subject: RTR and DECdtm I'm moving this off to its own topic, as we've moved on quite a bit from the original point of this thread. Forgive the length of what follows. On Wed, 23 Aug 2000 14:33:01 -0400, JF Mezei wrote: >Jim Johnson wrote: >> Finally, the 'VMS brains trust' may well have other reasons for >> pushing an RTR-everywhere solution. > >Since RTR is available for NT and Unix, I suspect that Compaq sees this as a >much more strategic product than any VMS-only "proprietary" solution. RTR can >outlive VMS should VMS die. And Compaq is not affraid to push solutions that >run on NYT or UNIX, so it is natural that we see Compaq push RTR instead of >some VMS-specific product. I was troubled by this, not because I didn't believe that this was a likely reason, but because its implicitly comparing apples and oranges. The problem is in the application paradigm. RTR, and other transaction queuing systems, act as reliable delivery mechanisms to execute atomic actions at an application. This means tha the stages of the overall action are separated in time as well as space. Therefore, the overall data flow will definitely break the isolation property in ACID, and may or may not break some other property (note that a well formed distributed application shouldn't -- it's just that there's nothing to stop it from doing so). DECdtm, and other atomic commitment protocols, provide a way for a distributed application to execute a number of steps as a single atomic action. These steps may be separated in space, but cannot be in time. Furthermore, while the commitment protocol itself guarentees nothing but an atomic decision, there is an extensive and well understood set of rules and middleware for ensuring that the ACID properties are preserved. In other words, these two things are almost perfectly complementary. RTR, et al, is how you deliver requests to islands of activity, and return information on their outcomes. DECdtm, et al, is how you ensure that those islands of activity can a) grow beyond a simple application and single database, and b) are internally ACID. A good example of using these in practice would be a reliable, scalable trading system (in fact, this is the sort of area RTR started out in). RTR forms the glue between the trader systems, which may be either simple user applications or automated database and transaction systems themselves, and the trading floor, could be a cluster-wide application that acted upon a set of files/databases under transaction control. In this example, the trader system executes a (possibly complicated) transaction, which includes queuing a request to RTR. Upon commit, RTR then reliably delivers the request to a trading floor system's application instance. That application executes a transaction, including the dequeing of the request from RTR, and inserting the final reply. Finally, the reply is delivered reliably to the trader system, which may or may not also read and process it under transaction control. You need both a reliable transaction queuing mechanism and a distributed (as in multiple resources and cluster-wide) commit protocol in order to make this work. Without both, some part of this story will start to fall apart with either resulting inefficiencies or non-transactional holes in the processing. Now, the way this came up had to do with the proprietary nature of DECdtm. Yes, the DECdtm protocol and API are proprietary. At the time it was built that was the effective choice available. X/Open hadn't yet started work on XA, and ISO was flailing about with their commitment protocols. There were no open standards to comply with. The only thing that came close was LU 6.2 from IBM, and it had assumptions about application structure that we simply couldn't adopt. However, since DECdtm was initially built, XA has provided a standard for the API, and TIP for the protocol. Could DECdtm be hidden behind them? I reviewed the XA spec several times as it was underway in X/Open, and am sure the answer is yes for it. While I've not given TIP the same level of attention, I do know people who have, and they concluded the answer was also yes. But why? What problems does providing these interfaces solve? Well, the reason for XA would be to be able to write a 2PC compliant application that is recompilable on another machine. There are some soft spots in the standard that may prevent this from being completely true, these are fairly minor. TIP, on the other hand, would allow a single global transaction to cross [system] vendor boundaries. E.g., a MTS transaction that used a application branch and database on a VMS machine. If you think these features are important, that they are costing Compaq lost revenue, then you should make that clear. XA and TIP would require work - not huge amounts, but work that would pull resources from somewhere else. Even if you think it is clear, don't assume that Compaq knows that. Jim. Jim Johnson Software Exploration, Ltd. Software Navigation and Discovery Tools