- From: Dan Weinreb <dlw@exceloncorp.com>
- Date: Tue, 26 Jun 2001 11:39:42 -0400 (EDT)
- To: mark.potts@talkingblocks.com
- CC: satisht@microsoft.com, mark.potts@talkingblocks.com, adambos@crossgain.com, www-ws@w3.org, henrikn@microsoft.com, joklein@microsoft.com
Date: Tue, 26 Jun 2001 08:19:02 -0700 From: "Mark Potts" <mark.potts@talkingblocks.com> There is no reason that a relaxed peer to peer structure for transaction coordination could not use 2PC, basically all participants are equal peers, except one peer either plays the role of initiator and coordinator( as well as participant ). The classic rule of peer to peer follows the "orwelian" theory that all are equal, just that some are more equal than others! Sure, that's all true. But there are still problems with using 2PC across business partners. Suppose Joe's Car Rental wants to order some pencils from Staples. Suppose Joe's computer acts as the transaction manager (TM) and starts a global transaction, and as part of this transaction Staples does some database lookups that become part of the global transction. Naturally, this seizes locks on Staples's database. And (assuming that you need real isolation) those locks have to be held until Joe says that he's done. Well, the people responsible for making the Staples database perform well have no idea how long Joe will hold the locks; maybe Joe is off talking to Office Max, and meanwhile holding the transaction open and therefore holding the locks, for a long time. This is not good for the Staples database; if locks are held for a long time, there's a much higher chance of lock conflicts causing delays. The people charged with operating the Staples database really don't want to allow some unknown and unrealted party (Joe's) to control the locks on their own database. -- Dan Weinreb eXcelon Corp.
Received on Tuesday, 26 June 2001 11:39:55 UTC