RE: Proposal: WebDAV and transactions

Hello Bita,

Although I think that Batch method can help regarding the transactions, but
it
is not enough. Because, it can only handle a transaction which made by a
sequence of WebDAV methods. However it is not the whole problem of
transactions.
Consider an application which is using WebDAV protocol as a part of it work
and
it needs to do some other functionality along with the WebDAV methods as
one
transaction. In this case my proposal of batch method doesn't help that
application. It would necessary need to TA-methods or change the server code
to
provide its own function. The latter one is an anathema.

Do I understand you right, that you think of a scenario, in which the
application wants to access/modify data from a (or multiple) WebDAV server
and from one (or many) TA aware different data sources (.e.g. an SQL
database) AND have that access/modification wrapped in a single TA.

In this case a two-phase commit protocol (and a Transaction Monitor) would
be required, assuming WebDAV supports TA (in the 2 phase commit flavor) and
all other associated DBs and datastores would support the 2PC protocol too.

We do not have this 2PC requirement, and I believe this could be an
extension to the proposed TA requirement. (at a minimum the TA_PREPARE
method needs to be supplied). Possible we could go two steps to reach this
2PC target.

Best regards,

Juergen



 -----Original Message-----
From: 	B. Shadgar [mailto:shadgar@cs.bris.ac.uk] 
Sent:	Wednesday, September 11, 2002 15.21 PM
To:	Roy T. Fielding; w3c-dist-auth@w3.org
Subject:	Re: Proposal: WebDAV and transactions


"Roy T. Fielding" wrote:

> > I think it is clear that the best way to address this requirement is
> > through
> > batching up WebDAV METHODS into a single request.  We also have
> > requirements
> > for doing batch methods for other reasons, and I know Microsoft has also
> > run
> > into this requirement and extended the standard this way.
>
> I don't think that is clear at all.  Batching methods does nothing to
> help with transactions that cannot be accomplished just as easily
> (and without breaking HTTP security) by including a transaction identifier
> in each request.  Changing the packaging of a sequence of interrelated
> requests does not change the fact that they are a sequence of interrelated
> requests.  Eventually, something has to process those requests in
sequence,
> as a transaction.  The server simply needs a way to accumulate requests
> and a method to commit them, and therefore it makes sense to have methods
> for begin-, abort-, and commit-transaction.

If you consider the proposal of batch method I have already sent to mailing
list, and if you consider that server would have the following schema of
handling a given method:

try {
     TA.begin();
     XXX Method();
    TA.commit();
} catch ( Exception e) {
    TA.rollback()
}

The whole of batch method would be considered as a one transaction without
having TA-methods like begin, abort and commit. For each request in the
Batch
method we just simply call the corresponding method which is not a separate
transaction.

>
>
> >> If the gun refuses to shoot you in the
> >> foot, that is a better design for the gun.
>
> In that case, a gun that is incapable of shooting at all would be
> a "better" design.  Considering requirements in isolation is a waste
> of energy.

I agree with this. Every body can make its choice to shoot or not.

>
>
> >> 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.
>
> It would do nothing to help protect the performance of the system.
> There is no effective difference between a sequence of requests with
> time-outs per request and a batch request with time-outs per read.
> The server still has to accumulate requests in storage and is
> subject to the same service problems with stateful behavior.
>
> The Web already has stored procedures.  There is nothing preventing an
> application developer from building complex transactions within a
> single method handler.  The problem is when you allow multiple methods
> with differing semantics to take place under the rubric of another
> method, which removes HTTP's ability to govern access rights per method.
>
> ....Roy

Although I think that Batch method can help regarding the transactions, but
it
is not enough. Because, it can only handle a transaction which made by a
sequence of WebDAV methods. However it is not the whole problem of
transactions.
Consider an application which is using WebDAV protocol as a part of it work
and
it needs to do some other functionality along with the WebDAV methods as
one
transaction. In this case my proposal of batch method doesn't help that
application. It would necessary need to TA-methods or change the server code
to
provide its own function. The latter one is an anathema.

If I am wrong please make me correct.

Regards
Bita.

Received on Wednesday, 11 September 2002 09:42:25 UTC