Re: UPDATE method and forking

Hi Werner,

comments inline:

>> Werner Donné <werner.donne@re.be> wrote on 03/16/2006 08:01:57 AM:
>> 
>>> Geoffrey M Clemm wrote:
>>> >
>>> > (1) Why does this scenario have to be in one transaction?  In
>> particular,
>>> > why isn't it sufficient just to wrap the sequence of operations in
>>> > a LOCK/UNLOCK?  
>>>
>>> Because anything in between can go wrong, leaving the system in an
>>> inconsistent state. It can't be the responsibility of the client to
>>> keep the state consistent. That is a co-operative and hence unreliable
>>> design.
>> 
>> The only thing that can go wrong is that the client neglects to perform
>> an UNLOCK, which is why there are timeout and administrative override
>> mechanisms
>> in the locking protocol.  But I agree that many clients would rather not
>> deal with locks, which is why we introduced the workspace feature.  So lets
>> focus on whether or not the workspace feature provides what you need.
> 
> Between each step in the sequence the dialogue can be interrupted. Not only
> would the lock not be released, but the checked-in version of the VCR could
> also be on another version than it was originally. This is an unexpected
> global state change for all clients, which is not acceptable in a concurrent
> system.
> 

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?

> 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?

> Again, I'm not discussing what I need. I'm not a user.
> 
>> 
>>> > (2) I agree that the locking mechanism is not designed to implement
>>> > transactional isolation.  That is what workspaces and working resources
>>> > are designed for.  If (for unexplained reasons :-) you don't want to
>>> > use the versioning features that were designed for transactional
>>> > isolation, it should come as no surprise that you have difficulty
>>> > achieving transactional isolation.  Some clients don't want/need
>>> > transactional isolation (they just want history to be kept, for
>> example),
>>> > which is why workspaces and working resources are optional features
>>> > (we define these two different ways of achieving transactional isolation
>>> > because some repositories can only support one, while other repositories
>>> > can only support the other, and we could find no way of unifying these
>>> > two different ways under a single feature).
>>>
>>> This is obviously not at all about what I want or don't want to use.
>>> I'm reasoning about the WebDAV model. I haven't said I was against
>> workspaces.
>> 
>> Well, to be honest, it is not at all clear to me what you do or do not
>> want to do (:-).  The purpose of the WebDAV model is provide a uniform
>> protocol for accessing the various authoring features provided by
>> a wide variety of repositories.  So the interesting questions are
>> "how do I as a client use the protocol to achieve this interesting
>> use case for a user" and "how do I as a repository use the protocol
>> to expose this particular feature of my repository to a client".
>> Without one of those questions in hand, one cannot have a productive
>> discussion about the WebDAV model.
> 
> I'm assessing the model, because I want to implement it. It is important
> that a model is consistent and stable, otherwise its implementation will
> be expensive. In my opinion exposing forking is not consistent. It is not
> because there is another feature that does the trick, that a particular
> feature shouldn't be scrutinised.
> 

Please explain in detail where you see inconsistencies. I can only see a 
non-linear version history so far, which is perfectly consistent.

> Inconsistent parts in a model have a life of their own and can have an
> impact on other areas of the model during evolution, just for the sake
> of compatibility.
> 
>> 
>>> > As for the why support forking, it is an (undesireable, but inevitable)
>>> > side-effect of parallel development.  So we don't define it as an
>>> > independent feature, but we "deal with it" for those features that
>>> > support parallel development (i.e., workspaces and working resources).
>>> > In particular, it is what tells you that parallel development has
>>> > occurred on a particular resource, and that therefore a merge is
>>> > required (the need for a merge when forking occurs is why it is
>>> > "undesireable").
>>> >
>>> > So creating forks in a non-parallel development context makes no
>> sense ...
>>> > you are just making trouble for yourself.  Which is why forking only
>>> > occurs as a side effect of parallel development, and not as a
>> feature that
>>> > you explicitly invoke.
>>>
>>> Which is what I reckoned and it is an encapsulation flaw. Clearly, forking
>>> on its own is useless, but it is exposed through the WebDAV interface with
>>> elements such as "checkin-fork", "checkout-fork", "fork-ok". There is no
>>> reason for this, nor for the UPDATE method to be allowed to change the
>>> checked-in version, which is the source of the problem.
>> 
>> The way WebDAV (and HTTP) achieves interoperability is by having a client
>> use a single uniform protocol against a wide variety of servers.  So the
>> client always uses the UPDATE method to "restore" a version from history,
>> whether it is working with a server that supports working resources,
>> supports
>> workspaces, supports both, or supports neither.  Changing the checked-in
>> version is important when the server supports either workspaces or
>> working resources, so you have clients uniformly use the UPDATE method.
>> This means that a client is aware of checkin-fork, checkout-fork, and
>> fork-ok behavior, so that in behaves properly when it is applied to a
>> server that supports either workspaces or working resources.
> 
> It strikes me that workspaces don't expose forking, while working resources
> do. Workspaces prove it is perfectly possible to offer branching and merging
> without exposing an implementation artifact such as forking. Note that they
> also make it possible to work transactionally within the repository without
> exposing transaction demarcation.
> 
> Workspaces are well designed, while working resources are not. Their difference
> should only about configurations, not in the way they offer branching. That
> should be exactly the same. The two things are orthogonal.
> 

The main difference between workspaces and working resources is, IMHO, 
whether the client controls the namespace or not. In both cases, you get 
multiple VCRs sharing a common version history. I really do not see a 
relevant difference in fork handling. What am I missing?


Regards,
Manfred






>> 
>>> Creating a new
>>> VCR in a workspace from a given version obviously requires forking, but
>>> that is merely an internal implementation matter.
>> 
>> No, it's part of the explicit user model, because when you invoke the MERGE
>> method, the result of the MERGE method is affected by whether or not
>> there has
>> been any branching, so the client needs to understand when a branch will
>> occur,
>> and when it won't.  
> 
> Merging and branching go together and you can do it with VCRs only. So there
> is no reason to offer another user model for branching than that of workspaces.
> Working resources should be made compatible with it.
> 
>> 
>> Cheers,
>> Geoff
>>  
>> 
>> 
> 
> Regards,
> 
> Werner.
> -- 
> Werner Donné  --  Re
> Engelbeekstraat 8
> B-3300 Tienen
> tel: (+32) 486 425803	e-mail: werner.donne@re.be
> 
> Received on Thursday, 16 March 2006 17:34:50 GMT
> 
>     * This message: [ Message body ]
>     * Next message: Manfred Baedke: "Re: rfc2518bis-14: locking terminology"
>     * Previous message: John Barone: "RE: rfc2518bis-14: locking terminology"
>     * In reply to: Geoffrey M Clemm: "Re: UPDATE method and forking"
> 
>     * Mail actions: [ respond to this message ] [ mail a new topic ]
>     * Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]
>     * Help: [ How to use the archives ] [ Search in the archives ] 
> 
> This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 16 March 2006 17:35:02 GMT

Received on Thursday, 16 March 2006 19:16:57 UTC