- From: Mark Potts <mark.potts@talkingblocks.com>
- Date: Tue, 26 Jun 2001 09:34:14 -0700
- To: "'Dan Weinreb'" <dlw@exceloncorp.com>, <mark.potts@talkingblocks.com>
- Cc: <satisht@microsoft.com>, <adambos@crossgain.com>, <www-ws@w3.org>, <henrikn@microsoft.com>, <joklein@microsoft.com>
Dan You are absolutely correct. I am not talking about 2PC with XA compliance, like I said in the original mail I agree that ACID transactions are not possible in the environment you lay out, there needs to be a conscious relaxing of Isolation and Durability, but the protocol could remain. In the case of Joe’s Car rental Joe acts as INITIATOR of the transaction and COORDINATOR. Staples acts as SERVICE PROVIDER and PARTICIPANT ( can be a SUBCOORDINATOR ). 1) Joe sends his order to the OrderManager Service at Staples, with context ( transaction id and an implicit or explicit request to PREPARE ) 2) Staples receives message and prepares local transaction for the order either choosing to block or commit and register a compensating transaction ) 3) Staples responds to the request ( and can add context to explicitly ENROLL, VOTE and timeout ) 4) If Staples are worried about the isolation inconsistency or the long lock ( dependant on how they chose to respond ) they can also offer a time out on the ENROLL and VOTE such that after lets say 1 hour the VOTE is void timeouts can be either positive or negative ) 5) Joe can now go off and look at anything else in the knowledge that he has one hour before he is either committed to the request or his order is cancelled - the same situation as booking a hotel room and having to cancel 48 hours prior, or booking a flight and having to confirm within 24 hours. 6) Joe decides Staples is the best price and thus decides to COMMIT, at which point Joe’s CORDINATOR initiates the TERMINATION phase by contacting the PARTICIPANTS enrolled in the transaction and issues an instruction to COMMIT or ROLLBACK. 7) Joe’s COORDIANTOR successfully receives COMMITTED or ROLLEDBACK messages from all the Participants ( in the case of a compensating model ) and can thus issue a COMPLETED message to PARTICIPANTS causing them to de-register their compensating registrations. Of course Durability and Isolation are relaxed in the case of compensation rather than using XA compliant 2PC, and if you absolutely insist on Isolation then you have to expose XA complaint resources ( as a TIP implementation requires and some of the EJB vendors are now trying to do WebLogic 6.1 ) 1-5 = PREPARE phase of 2PC and 6-7 represents the TERMINATION phase Regards, Mark Potts -----Original Message----- From: Dan Weinreb [mailto:dlw@exceloncorp.com] Sent: Tuesday, June 26, 2001 8:40 AM 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 Subject: Re: Web Services and transactions 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 12:28:00 UTC