Re: UPDATE method and forking

A few initial comments, and then additional comments in-line:

The reason for supporting locking is not because locking is a good way
to do parallel development on a versioning server (it isn't), but rather
because there are a lot of WebDAV locking clients out there, and we
want to ensure that they work as well as possible against a versioning
server.  So when we argue that "locking works", we aren't saying that
locking is a good way to solve this problem, but rather that if you have
a locking client, it will interoperate well with a versioning server
that supports the RFC-3253 versioning protocol.

The reason for supporting working resources is not because it provides
a good model for clients to work with (it doesn't), but rather that
it provides a different distribution of work between the client and
server.  In particular, with a workspace server, all of the work is
being done on the server, which means clients are much simpler to write.
With a working-resource server, a large part of the work has to be done
on a client (effectively, the client implements a client-side 
workspace, using local persistent state on the client, and the
low-level working-resource mechanisms provided by the server),
but because the server (the shared resource) does
significantly less work, it is actually much simpler to write a scalable
system using the working-resource mechanism than it is to write one
using the workspace mechanism.  This was the one architectural choice
which we found we couldn't hide beneath a common protocol (and I can
vouch for the fact that we tried very hard for a very long time to
do so). 

In that context, some additional comments below:


Werner wrote on 03/17/2006 03:41:06 AM:
> Manfred Baedke wrote:
> > 
> > So the checked-in version of the VCR changed. Every client (at least
> > those who do not hold a lock) must be aware of this possibility at any
> > time. Why should this be unexpected?
> 
> Several clients can be executing such scenarios at the same time with 
the
> same VCR. In order to avoid sudden changes of the checked-in version 
they
> all have to use locking. Locking, however, is not mandatory, so it is up
> to the clients to make sure there are no races. This is a co-operative
> process. 

A single locking client on its own can ensure there are
no races by taking out the lock.  An attempt to modify this resource by
any method (PUT, UPDATE, MERGE) by another client will fail while the 
client
has the lock.  The only time co-operation is required is amoung a group of
non-locking clients ... but in this case they use etags, which will also
work against a versioning server.  To emphasize the point made above, this 
is
not an argument that locking the VCR is a good way to handle this problem 
...
it is an argument that existing locking clients will interoperate in a 
reasonable
way with a server that supports RFC-3253.

> It is like saying that multiple clients can update tables in a
> database, but they have to manage table or record locking themselves. It
> was like that decades ago.

Yes, but if you have thousands of deployed clients (written years ago
when there was no workspace protocol) that do this table and
record locking management, it is a very good thing if they will just work
unmodified against the new versioning servers.

> The forking and update mechanisms require isolation and locking is not
> the good instrument for that. Workspaces achieve concurrency in a 
natural
> way without imposing co-operative scenarios with locking. This is both
> safer and simpler.

Totally agree.  Newer clients that take advantage of the workspace 
protocol
will be much easier to write than it was to write the older clients that 
only
could use the locking protocol.

> >> Regarding the lock release the timeout mechanism is not good enough 
if
> >> locking is used like that, because VCR is blocked too long. This 
impacts
> >> concurrency severely. When a transaction fails, for example, 
everything
> >> is rolled back and release immediately.
> > 
> > Yes, long lasting exclusive locks are evil. Again, why not use
> > workspaces or working resources?
> 
> They are not evil if the repository supports branching. It is common to
> reserve a branch, because branches are a tool to let people work 
together
> on the same topic. Long-lasting locks should not be used on the 
integration
> branch in which all work will be merged.

A branch is modeled in the WebDAV protocol as an "activity".  Note that
we use the term "reserve" for what you do to a branch, to avoid confusion 
with the
"lock" protocol.  The lock protocol was not used for reserving branches,
because we didn't want the client to have to maintain lock tokens for the
branch they are working on.

> > Please explain in detail where you see inconsistencies. I can only see 
a
> > non-linear version history so far, which is perfectly consistent.
> 
> You have two alternatives for working in parallel, where one suffices. 
One
> method, working resources, exposes physical aspects such as forking and
> puts the resposibility for integrity at the client. The other is 
abstract.
> It doesn't expose implementation details, because each "branch" has its
> own VCR and the checked-in version of each VCR can be left to be the 
most
> recent version. The integrity responsibility is within the server.

Yes, I agree that the workspace protocol allows for much simpler clients
to be written.

> The only functional difference there is supposed to be between 
workspaces
> and working resources is that the latter work in their own 
configuration,
> a term that is nowhere defined by the way prior to section 9 of RFC 
3253.

Actually, it is section 10.2 ... "Advanced Versioning Terms".  Before 
then,
it was just used in an informal descriptive way, and was not part of the 
protocol.

Since my repository supports workspaces, I did try for quite a while to
convince the standards group that we only needed to support workspaces, 
but
the reality is that there are repositories that do not (and cannot) 
support
workspaces, but do support working resources, and unless we defined
working resources support in the protocol, clients would not be able to
interoperate in a useful way with those repositories.

> That makes it still possible to use workspaces in a client that would 
have
> to resort to working resources. Workspaces are now positioned as a pure
> server functionality. They are, however, an abstract mechanism that can
> be perfectly implemented differently in a real server and in a 
stand-alone
> client. For the latter the implementation may be lighter because there 
is
> perhaps no cuncurrency, making the preservation of integrity easier. It
> is as if such a client has its own built-in server.

But from a protocol perspective, you cannot hide this difference.  This is
in fact one of the major reasons why we started JSR-147, which is a 
client-level
API rather than a client-server protocol.  In JSR-147, there is only the
workspace model, because in a client API, you can hide the implementation 
choice
of "fat client" (working-resource model) or "skinny client" (workspace 
model)
under the client library layer that supports the JSR-147 API.

Cheers,
Geoff