DDJ: What is interesting is that the web is here today, and it works, yet it uses none of those algorithms really.
JG: Well, you would be surprised. It uses quite a few of the algorithms. If you go and visit most commercial web sites, they show you your transaction. They say, okay, this is what you want to do. Then, you can say cancel, or you can say confirm. That is the two-faced commit protocol. Once you say "confirm" or "submit", then it is going out across the web. It is going to the web server. Typically, then, it is going to a database system that is in the back end that is doing the little dance. Part of that little dance is to go off to your credit card company and go through a little two-faced commit with him to debit. I think, in fact, that much of the technology I described, which is the journalizing, undo, redo, two-faced commit, and concurrency control is, in fact, being applied if you think of the web for e-commerce. If you think of the web for browsing, web sites, and downloading videos or MP3s, you're right.
DDJ: I think my point was that the second phase where having distributed sites somehow, be aware of each other, transaction theory, transactions on a distributed model hasn't really arrived yet and probably never will.
JG: It is interesting. The sites that I am familiar with, which are large sites have quite a bit of data replication where the same data is stored in multiple locations. They use transaction mechanisms to manage that replication, if it is a database system. Microsoft has this thing called SQL server. It has a replication model. It think Sybase, Oracle, DB2, and Informix have a similar transactional oriented replication system. If you look at web sites and web servers which are doing data replication they are using transactions a lot. If you look at a bank where it is doing funds transfer, within the bank, routinely they are using distributive transactions. On the other hand, if you look at electronic mail systems they are taking a completely different approach. They just keep sending you the message and sending you this message until you acknowledge it. That is the way they get the all, or nothing, behavior. They, in fact, are not using transaction theory.
DDJ: Let's go back to IBM. How do we fast forward it. How do we get to this work that you were doing at IBM and. . . I assume there weren't many groups in the country working on this technology. How do we get from there to real products and from real products to the situation we have now where we have a choice of SQL database products.
JG: Frankly, we were working on this. We just thought this was a great idea. We were having a lot of fun. This predated an era where everybody expected to get fabulously rich working in the computer business. It was much more scholarship and excitement with the technology. It turned out that there was a company that had a product called "Adabase". They were cleaning IBM's clock in the low end. The European sales organization came to IBM and said, "We need to have a low end and easy to use simple database system."
DDJ: At that point none of the work that your group was working on had ever made its way into a product?
JG: True. There was a related project called "Query by Example" that was much more focused on user interface and had a gooey, tabular interface to a database system. In fact, that was available through some channel at IBM, but it was considered sort of a one often and wasn't "strategic". Also, at about this time were had been writing lots and lots and lots of papers. There was this guy Larry Ellison who called us up one day and said, "Can I have the error codes for the SQL?" We said, "You know, we don't think we really want to give you the error codes." Larry had, I think, a contract from the National Security Agency to build a SQL system for them. That thing bumbled along and, eventually, become Oracle Corporation, multi-billion dollar. . . Many people, now, have heard of Larry Ellison and Oracle. There was a related group at UC Berkeley, lead by Mike Stromberger, Gene Wong, and Larry Brough that was working on a system called "Ingres". In about 1971, those folks got a little bit of venture capital and started a company called Ingres. It was originally called "Relational Systems Incorporated". Then, it was called Ingris. Eventually, it was acquired by Computer Associates. There was a company Informix. Informix also read the SQL papers, from the guys in IBM San Jose, and went off an implemented a SQL like system. You now have Informix, Ingres, Oracle, and IBM has not yet brought a product.
