RE: Transactional Web Services ? (was: a very long subject with weird spaces inside)

[David Orchard <orchard@pacificspirit.com>]

Hi Nicolas,

The problem with 2pc over the web isn't whether it can be done or not. 
 That's easy.  The problem is whether it can scale.  One of the huge 
advantages that the web has over every distributed object protocol is that 
a client doesn't lock resources on the server.

If you offer web services where a client can lock resources, you can't 
scale the same way that the web currently does.

Database connections are one example.  It most web systems, you multiplex 
many incoming client request through database connections.  A typical 
scenario might be 30 database connections serving potentially hundreds of 
web server threads.  But you can never scale the database connections as 
fast as your web server threads.  And you almost always have to restart 
your db connection when something goes wrong with the connections, as the 
database has a really tough time reclaiming "lost" connections.

The same applies to web services, in that 2pc locks resources for a 
potentially long time and you don't know when a client goes away.

Cheers,
Dave

On Wednesday, August 22, 2001 3:57 PM, Nicolas LEHUEN 
[SMTP:nicolas.lehuen@ubicco.com] wrote:
> Thanks for the pointer, I'll have a look at it.
>
> I once implemented a custom version of RMI that included a 2PC protocol
> (which a transaction coordinator and all). The wire protocol was just a
> one-way, peer-to-peer message sending system. Messages were serialized 
Java
> objects. I did all this in order to better understand CORBA, RMI and
> distributed transactions.
>
> I based all the transactional parts on my reading of two books, one being 
a
> french book, the other being "Concurrent Programming in Java, 2nd 
Edition"
> from Doug Lea (Addison Wesley), chapter 3.6. From those books I learned 
that
> transactions and 2PC are not voodoo. In fact the methods and requirements 
to
> build a transactional system are not complicated (though they can be
> expensive to put in practice).
>
> Anyway, the conclusion is that you can implement a distributed 
transaction
> system with 2PC on a one-way, peer-to-peer messaging protocol.
>
> The current web services infrastructure is of course not ready for this, 
but
> it'll have to tackle with the problem and solve it.
>
> Regards,
> Nicolas
>
> -----Message d'origine-----
> De: David Orchard
> A: 'xml-dev'
> Date: 22/08/01 22:45
> Objet: RE: "Uh, what do I need this for" (was RE: XML.COM:  How I Learne
> d t o Love daBomb)
>
> <mondo snip/>
>
> You presume that transactions between web services is a good and
> possible
> thing.  Most people think of 2 phase commit when they think
> transactions,
> and I have serious doubts about that.  Satish Thatte wrote a good
> position
> paper referencing this, http://www.w3.org/2001/03/WSWS-popa/paper39.
> One
> summary would be that 2PC doesn't for web services.
>
> If you mean long-running or compensating transactions, then I agree that
>
> transaction support will be required.
>
> Cheers,
> Dave
>
> >
> > Note that we have a bigger problem which is the non-support of
> transactions
> > by the current web services protocols. We use a kind of architectural
> > workaround for now (based on the fact that we "only" implement an
> > aggregation and presentation layers), but there is no doubt
> transaction
> > support will be required one day.
> >
> > That's the reason why I am kind of skeptical about a transactional B2B
>
> use
> > of web services with the current technologies. But as a distributed
> > transaction relies basically on the propagation of the couple
> {transaction
> > monitor ID,unique transaction ID} accross processes, I don't think
> this
> is
> > something that can't be done with SOAP.
> >
> > Regards,
> > Nicolas
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.xml.org/ob/adm.pl>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>