RE: Web Services and transactions

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