Subject: [caldav] Retry request status

From: Mike Douglass <[email-masked]>
Date: Fri, 12 Mar 2010 14:04:58 -0500

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                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: Tim Olsen <[email-masked]>
Date: Fri, 12 Mar 2010 14:17:14 -0500

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

I recommend a 503 with a Retry-After header.  See
http://www.greenbytes.de/tech/webdav/rfc2616.html#status.503

Tim

---

From: Mike Douglass <[email-masked]>
Date: Fri, 12 Mar 2010 14:21:04 -0500

I looked at that as well:

conflict seemed to carry the sense of what was happening: I''d be happy
with either though

--

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 12 Mar 2010 14:34:25 -0500

Hi Mike,

> conflict seemed to carry the sense of what was happening: I''d be happy

I think you will find iCal.app handles the 503 the way you want, but not 
perhaps the 409.

-- 
Cyrus Daboo

---

From: Mike Douglass <[email-masked]>
Date: Sat, 13 Mar 2010 23:13:05 -0500

Would it be appropriate to document this approach?

Cyrus Daboo wrote:
> I think you will find iCal.app handles the 503 the way you want, but
> not perhaps the 409.
>

--