- From: Babich, Alan <ABabich@filenet.com>
- Date: Mon, 9 Sep 2002 12:36:26 -0700
- To: "'Julian Reschke'" <julian.reschke@gmx.de>, "Pill, Juergen" <Juergen.Pill@softwareag.com>, w3c-dist-auth@w3.org
The database vendors faced the issue of transactions in a client-server network when they distributed their databases some ago. The naïve approach of just remoting each database call was a performance disaster on large networks. That is why they invented database script programming languages and stored procedures. Stored procedures are scripts (in a database programming language) that allow fairly general database transactions to be programmed. These scripts are stored in the database. Clients invoke the scripts by passing them parameters. Besides performance, one of the advantages of stored procedures is standardization of the database processing. The system doesn't have to depend upon every client getting the update processing correct. The stored procedures can theoretically enforce all the checking and standardization required. If one limits who can write stored procedures to a small trusted group, the integrity of the system is protected. As you pointed out, it is sometimes the case that the processing involved in WebDAV transactions as you envision them is conditional on the result of previous processing steps. If you give people a gun they can shoot themselves in the foot with, then a certain percentage of the people will shoot themselves in the foot. (I know someone who literally did that.) If the gun refuses to shoot you in the foot, that is a better design for the gun. In the spirit of that analogy, I am proposing that the entire transaction, conditional processing and all, should be invoked by one method call. That would do a lot to help protect the performance of the system. Within the single-method constraint, there are two ways to go: (1) Specify the entire transaction, conditional processing and all, within the stuff you send over the network in the method invocation. (2) Invent stored WebDAV procedures that specify WebDAV transactions (conditional processing and all), and have the method pass parameters to the stored procedure. You could think about taking either or both of these approaches. It is an open question as to whether either of the above two approaches can be done well without doing violence to HTTP and/or WebDAV. Alan -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, September 09, 2002 7:34 AM To: Pill, Juergen; w3c-dist-auth@w3.org Subject: RE: Proposal: WebDAV and transactions Jürgen, I think the main issue isn't that people aren't interested -- it's more that they (well, I) think that it's an extremely bad idea that doesn't adher to the HTTP model. In particular, it would make the meaning of an HTTP method invocation depend on previous method calls. That makes it hard or impossible for intermediaries to work with these messages. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen > Sent: Monday, September 09, 2002 4:17 PM > To: 'w3c-dist-auth@w3.org' > Subject: RE: Proposal: WebDAV and transactions > > > > Hello, > > I did not receive a lot of feed-back on the TA "proposal" (and the > statements were both positive and negative). > > Would you agree on the statement, the WebDAV group would be currently not > interested in standardizing TA methods? > > As we would need this extension for the API implementation, our > option would > be to implement a proprietary WebDAV TA extension available on our server > only. > > If the interest on this topic would raise again - possibly at a > later time - > we would be happy to share our experience with you. > > Best regards, > > Juergen Pill > > > > -----Original Message----- > From: Pill, Juergen [mailto:Juergen.Pill@softwareag.com] > Sent: Monday, September 02, 2002 12.24 PM > To: 'w3c-dist-auth@w3.org' > Subject: Proposal: WebDAV and transactions > > > Hello, > > The current WebDAV specifications deal with a transactional support on a > method base only. Either a single WebDAV method is completely and > successfully executed, or the method is not executed at all (e.g. a > PropPatch command will either modify all requested properties or none of > them). A transactional support spanning multiple WebDAV methods > is currently > not specified. > Multi user requirements are either handled in separate workspaces > (Delta-V) > or via the Lock method. > During our discussion on the JSR 170 (Content Management API) > implementation > on top of WebDAV, we believe that we require longer transactions spanning > multiple separate WebDAV methods. (This issue was already partially > discussed in the Batch method thread). Do you also fell the > need/requirement > to get a standard on the way, concerning a transactional WebDAV protocol > extension? > > A possible use case would be: > An author wants to modify an html page. To successfully do so, he will PUT > the updated html page back, PROPPATCH and UNLOCK it, DELETE all bitmap > files, which are not references any more, and PUT (create) the newly > referenced bitmaps files. If he wants to ensure, that either all > his changes > do apply (or none of them) he would surround those method call with an > TA-BEGIN and a TA-COMMIT method call. If the author would be an API (e.g. > JSR 170) exposing the TA functionality to an application, we believe this > feature to be mandatory. > > A possible (starting) specification could be: > WebDAV defines 3 additional methods: TA-BEGIN, TA-COMMIT and TA-ABORT. The > TA-BEGIN method will return a TA token (e.g. via an XML response > body). This > TA token will be send to the following WebDAV methods, which are part of > this transaction (e.g. via an additional header). The TA-COMMIT > or TA-ABORT > method will either commit or abort the transaction and invalidate the TA > token. > If and when an open TA, which is not used any more, is aborted, could be > controlled similar to the lock method timeout header. > All WebDAV methods, which either do not posses a TA token, or posses an > invalid token are handled as today (the method is executed within its own > TA), this would ensure upward compatibility. > This extension would be optional, if a server supports the TA methods, it > will state this in the OPTIONS request (similar to Delta-V). > > > Does this make sense? > > Best regards > Juergen Pill >
Received on Monday, 9 September 2002 15:37:03 UTC