Una de las dudas que surgieron en el Webcast de Client Object Model fue sí era posible controlar la concurrencia en las actualizaciones desde el API. La pregunta fue: ¿Al trabajar de manera asíncrona, cómo podemos controlar actualizaciones concurrentes de varios usuarios?

La respuesta fue fácil: Pues me alegra que me hayas hecho esa pregunta, no había reparado en esa posibilidad y no tengo respuesta.

Pues bien, después de algunas indagaciones y de algun que otro ejemplo con SharePoint, he encontrado una respuesta.

Recordemos que estamos trabajando sobre SharePoint y que los conflictos de versiones los resuelve con el siguiente mensaje:

Esto obliga al usuario a volver a la lista, actualizar el navegador y reescribir los cambios que había realizado en el elemento para actualizarlo. La solución no es mala, pero es un problema que se le deja al usuario para resolver.

Bien, ahora que sabemos como se resuelven los conflictos en SharePoint, nos podemos imaginar como se van a resolver desde el Client Object Model. Si provocamos este tipo de conflicto desde Silverlight, utilizando el Client Object Model, la llamada al ExecuteQueryAsync no se ejecuta satisfactoriamente y se lanza una exception, que capturamos con el ClientRequestFailedEventHandler, que nos cuenta lo siguiente:

Al final tenemos algo parecido a lo que se obtiene si provocamos el conflicto desde la aplicación web de SharePoint, un tipo de error Microsoft.SharePoint.Client.VersionConflictException, que nos obliga a ayudar al usuario a recargar los datos y que vuelva a escribir los cambios para que se produzca la actualización.

Simplemente SharePoint utiliza un control de versiones para identificar que, tanto el Cliente Object Model como el API de servidor, realizan los cambios y las actualizaciones sobre la última versión que se encuentre almacenada en el servidor.

Saludos a todos…