Andrea Campi <a.campi <at> inet.it>
2002-08-02 20:29:36 GMT
On Venerdì, agosto 2, 2002, at 09:47 , John Stracke wrote:
> Doug Royer wrote:
>> Yes. And if we did require the CS to do that (removal), then for
>> implementations that have transaction enabled databases
>> behind them - it would work safer.
> Right. And, for those that don't, it can't be made safer (unless they
> want to implement transactions themselves, which, ah, will give them
> some time-to-market problems .
Well, it wouldn't be hard to support an atomic command to do this. You
just need to make sure you don't delete UNPROCESSED entries which might
arrive while you are deleting them - I can think of at least 2 ways to
do this [*].
> It might be clearer to add a new command to consolidate the entries,
> rather than having a DELETE happen as a side effect of CREATE. In that
> case, we'd add the restriction that CREATing a BOOKED entry will fail
> if there's an UNPROCESSED entry with the same UID.
I was about to agree with Doug (having the server delete the UNPROCESSED
entries), but you do have a point here.
I guess it would be better if we had a command to consolidates entries.
A server might not implement it; in that case, the client should
fallback to deleting the entries by itself, and take the hint that it
might not be safe to do that.