Re: UPDATE method and forking

Hi Geoff,

I understand now that there is in fact legacy to support, which is
fair enough. So Manfred doesn't have to answer the question in my
previous post anymore. The conclusion is important, because it
comes down to the choice whether an new server implementation wants
to support those older clients or not.

The JSR-147 initiative seems interesting. How does it relate to
JSR-170? Sections 4.10 and 4.11 of the latter may overlap.

Regards,

Werner.

Geoffrey M Clemm wrote:
> 
> 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

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be

Received on Friday, 17 March 2006 15:48:20 UTC