[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
- [caldav] Retry request status Mike Douglass
- Re: [caldav] Retry request status Tim Olsen
- Re: [caldav] Retry request status Mike Douglass
- Re: [caldav] Retry request status Cyrus Daboo
- Re: [caldav] Retry request status Mike Douglass