W3C home > Mailing lists > Public > www-ws@w3.org > June 2001

Re: Web Services and transactions

From: Dan Weinreb <dlw@exceloncorp.com>
Date: Tue, 26 Jun 2001 11:39:42 -0400 (EDT)
Message-Id: <200106261539.LAA15342@handcuff.odi.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:06 UTC