Leaving aside the question of whether pessimistic locking over the web
is a good or bad, I would expect a lock at the end of this operation.
This of course, leads to the pattern that the author(s) of RETRO tried.

Subbu

On Jul 4, 2009, at 4:08 PM, Jan Algermissen wrote:

>
> On Jul 4, 2009, at 7:04 PM, Subbu Allamaraju wrote:
>
>> Just curious - why would the server want to offer such a
>> functionality
>> as locking to its clients?
>
> Because it is (currently) a requirement of the owners of the system
> to use a pessimistic locking strategy, IOW, not HTTPs conditional
> write approach with If-Match.
>
> Jan
>
>
>
>>
>> Subbu
>>
>> On Jul 3, 2009, at 7:01 PM, Jan Algermissen wrote:
>>
>>>
>>>
>>> Hi,
>>>
>>> suppose a situation where clients know that creating a lock on some
>>> resource
>>>
>>> http://www.example.com/docs/1234
>>>
>>> is done by PUTing to
>>>
>>> http://www.example.com/properties/1234?lock
>>>
>>> I see two ways how to address the situation that the lock can alreay
>>> exist and that the
>>> request should then fail:
>>>
>>> a) PUT /properties/1234?lock
>>> If-None-Match: *
>>>
>>> 304 Precondition Failed
>>>
>>> b) PUT /properties/1234?lock
>>>
>>> 409 Conflict
>>>
>>> The former bears the question what the server should do when the
>>> client does not make
>>> the request condtional (-> 409??) and regading the latter I am not
>>> sure if the semantics
>>> are correct.
>>>
>>> Can anybody provide a clue?
>>>
>>> Jan
>>>
>>>
>>>
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>