Re: UPDATE method and forking

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.

> 
> (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.

> 
> 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. Creating a new
VCR in a workspace from a given version obviously requires forking, but
that is merely an internal implementation matter.

> 
> Cheers,
> Geoff
> 

Regards,

Werner.

> 
> 
> Werner Donné <werner.donne@re.be> wrote on 03/16/2006 05:12:06 AM:
>> Geoff,
>>
>> I understand it can be done like that, but I have two remarks:
>>
>> 1) Such a scenario should in fact be one transaction. The proposed
>>    solution doesn't protect integrity. Currently the choice is not
>>    to expose transaction demarcation to the client. That implies
>>    the WebDAV model shouldn't expose scenarios which require transactions
>>    either.
>>
>> 2) The locking mechanism in a versioning system is not designed to
>>    implement transactional isolation. It is merely for long-duration
>>    reservations of versions.
>>
>> I agree that workspaces are the feature for working in parallel, but
>> what is then the use of forking? Which problem does it solve?
>>
>> Regards,
>>
>> Werner.
>>
>> Geoffrey M Clemm wrote:
>> >
>> > If you don't want to use either workspaces or working resources,
>> > then you would just use the base WebDAV functionality for handling
>> > multiple clients concurrently updating the same resource, i.e. locking.
>> >
>> > So in your original sequence, just wrap the sequence in an LOCK/UNLOCK
>> > pair, i.e.:  
>> >
>> > LOCK the version-controlled resource
>> >> - Retrieve the current checked-in version. (PROPFIND)
>> >> - Set it to the most recent version in a "branch". (PROPFIND, UPDATE)
>> >> - Perform a check-out or anything else that can be done on a version
>> >>   controlled resource. (CHECKOUT, GET, PUT, CHECKIN)
>> >> - Set the checked-in version back to what it was. (UPDATE)
>> > UNLOCK the version-controlled resource.
>> >
>> > Cheers,
>> > Geoff
>> >
>> > Werner wrote on 03/15/2006 08:31:46 AM:
>> >> I'm not referring to working resources and I know that normally
>> >> workspaces should be used to work in parallel. However, the
>> >> workspaces feature is optional and the checkout-in-place feature
>> >> doesn't depend on it. The checkout-in-place feature provides
>> >> forking and therefore the model should be consistent in the
>> >> absence of the workspaces feature.
>> >>
>> >> According to me forking and workspaces are unrelated. The forking
>> >> functionality stands on its own. When a fork is allowed for some
>> >> version, it may have more than one successor. The only way to
>> >> address a particular successor, for a check-out operation for example,
>> >> is by setting the checked-in version of the VCR to it. This is a
>> >> global state change.
>> >
>> >
>> >> Geoffrey M Clemm wrote:
>> >> >
>> >> > I believe you are confusing the "checkout-in-place" feature and
>> >> > the "working-resource" feature.  
>> >> >
>> >> > In the "checkout-in-place" feature, you make your changes
>> >> > directly on the VCR.  If two clients want to be working
>> >> > in parallel, they would have separate workspaces, and each
>> >> > client would have its own VCR, so the VCR is not shared global
>> >> > state, but rather is private state for the client that owns
>> >> > that workspace.
>> >> >
>> >> > In the "working-resource" feature, you do apply the
>> >> > CHECKOUT directly to a version (see section 9.3), so again,
>> >> > there is no mutable global state for which there would
>> >> > be contention.
>> >> >
>> >> > The only time in which there is shared mutable state is when
>> >> > two clients are sharing the same workspace.  In this case,
>> >> > the primary problem you face is the standard "lost update" problem
>> >> > while you are authoring the content, and the solution is the
>> >> > standard WebDAV solution: use the LOCK method.
>> >> >
>> >> > Cheers,
>> >> > Geoff
>> >> >
>> >> > Werner wrote on 03/15/2006 04:30:19 AM:
>> >> >>
>> >> >> The UPDATE method can be used to set the checked-in version of a
>> >> >> version controlled resource to a version which has descendants.
>> >> >> At that point a check-out may fork, resulting in the checked-in
>> >> >> version to have more than one descendant.
>> >> >>
>> >> >> This way a tree can be built. If one wants to grow the different
>> >> >> branches of such a tree, the UPDATE method should be used to set
>> >> >> the checked-in version of the version controlled resource
>> >> >> appropriately. This, however, changes global state, which could
>> >> >> lead to races.
>> >> >>
>> >> >> The complete operation the client would do is the following
> sequence:
>> >> >> - Retrieve the current checked-in version of the version controlled
>> >> > resource.
>> >> >> - Set it to the most recent version in a "branch".
>> >> >> - Perform a check-out or anything else that can be done on a version
>> >> >>   controlled resource.
>> >> >> - Set the checked-in version back to what it was.
>> >> >>
>> >> >> For this to work in a multi-user environment, either the sequence
>> >> >> should be executed atomically and in isolation, or methods such as
>> >> >> check-out should be allowed to operate on versions as well.
>> >>
>> >> --
>> >> Werner Donné  --  Re BVBA
>> >> Engelbeekstraat 8
>> >> B-3300 Tienen
>> >> tel: (+32) 486 425803   e-mail: werner.donne@re.be
>> >>
>>
>> --
>> Werner Donné  --  Re
>> Engelbeekstraat 8
>> B-3300 Tienen
>> tel: (+32) 486 425803   e-mail: werner.donne@re.be

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

Received on Thursday, 16 March 2006 13:02:03 UTC