[caldav] Retry request status

Mike Douglass <douglm@rpi.edu> Fri, 12 March 2010 19:04 UTC

Return-Path: <douglm@rpi.edu>
X-Original-To: caldav@core3.amsl.com
Delivered-To: caldav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 686923A698B for <caldav@core3.amsl.com>; Fri, 12 Mar 2010 11:04:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJqkmlEDfHp7 for <caldav@core3.amsl.com>; Fri, 12 Mar 2010 11:04:54 -0800 (PST)
Received: from smtp8.server.rpi.edu (smtp8.server.rpi.edu [128.113.2.228]) by core3.amsl.com (Postfix) with ESMTP id AD8E13A6971 for <caldav@ietf.org>; Fri, 12 Mar 2010 11:04:54 -0800 (PST)
Received: from [128.113.124.235] (kiva-07.dynamic2.rpi.edu [128.113.124.235]) (authenticated bits=0) by smtp8.server.rpi.edu (8.13.1/8.13.1) with ESMTP id o2CJ4wnG025794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <caldav@ietf.org>; Fri, 12 Mar 2010 14:04:58 -0500
Message-ID: <4B9A905A.2060804@rpi.edu>
Date: Fri, 12 Mar 2010 14:04:58 -0500
From: Mike Douglass <douglm@rpi.edu>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: caldav@ietf.org
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-RPI-SA-Score: undef - SENDER Whitelisted (douglm@rpi.edu: Mail from user authenticated via SMTP AUTH allowed always)
X-CanItPRO-Stream: outgoing
X-Canit-Stats-ID: Bayes signature not available
X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.228
Subject: [caldav] Retry request status
X-BeenThere: caldav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <caldav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/caldav>
List-Post: <mailto:caldav@ietf.org>
List-Help: <mailto:caldav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2010 19:04:56 -0000

Hibernate and other systems support optimistic locking
http://en.wikipedia.org/wiki/Optimistic_concurrency_control particularly
appropriate when long running web operations are taking place.

This works well for us in practice - hibernate will report a
StaleStateException if a conflict arises and we almost never see them -
except when running tests.

This does raise the possibility though, that as traffic increases, the
concurrent activity affecting a small number of users will increase, in
particular when we have a group of users or resources all with auto
accept on for scheduling.

Some of this is handled by ETag and If-Match headers but there are still
occasions when a conflict will arise.

For CalDAV clients an appropriate action would often be to simply retry
the request. I have looked at whether this is achievable within the
server and it's a little problematic. Am I on my own with this or do
others have situations in which requesting the client to just retry the
request is appropriate?

I'm thinking of a 409 response with an error response like <DAV:retry/>




-- 

Mike Douglass                           douglm@rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180