Existen muchos temas que con el pasar del tiempo y las nuevas facilidades que tienen los frameworks que vamos incorporando al proceso del desarrollo del software tendemos a dejar de lado. Uno de estos temas es el manejo de la concurrencia cuando utilizamos el entity framework.
Concurrencia Optimista vrs Concurrencia Pesimista
Existen dos escenarios claves a la hora de manejar la concurrencia en las aplicaciones, el optimista y el pesimista. En el primer caso – el optimista – muchos clientes pueden acceder el registro y de ser el caso modificarlo, eliminarlo o solo consultarlo; en este caso el cliente que haga la última modificación es el que prevalece – excepto por el borrado. En el caso de la concurrencia pesimista un cliente bloquea el acceso a un registro y nadie más puede efectuar una operación sobre el mismo; en este caso, pueden existir variaciones de comportamiento ya que el cliente lo puede bloquear para lectura, por lo tanto otros clientes podrían bloquearlo para lectura también pero no para cambios. Los escenarios pesimistas por lo general son muy complicados de programar – aunque hay situaciones en donde es la única opción. En el caso del Entity Framework se utiliza la concurrencia optimista, por lo que se debe de tener mucho cuidado a la hora de trabajar con este tema.
Trabajando con la Concurrencia Optimista
Para entender mejor el tema, vamos a crear un ejemplo muy simple en donde vamos a ver como reacciona el Entity Framework a la concurrencia. En este ejemplo, vamos a obtener un registro para editar – voy a usar el MVC 3 – y luego desde otra sesión voy a editar el registro y voy a ingresar el dato antes que la primera sesión lo haga.
La tabla que vamos a utilizar es la siguiente:
Esta tabla fue generada a partir de los objetos pocos que fueron creados en el proyecto. El objeto POCO que generó esta tabla es el siguiente:
Aunque esta tabla tiene una relación a las asignaciones, para este ejemplo no vamos a utilizar dicha relación. Ahora se genera el scaffold para editar, eliminar y modificar un registro del tipo consultor con el MVC, el resultado final es el siguiente:
El siguiente código es el de la actualización del registro. Al ser esta una aplicación n-layer se crean instancias del poco y se invocan métodos de la lógica de negocios.
Ahora vamos a proceder a interactuar con el sitio web para demostrar que pasa con la concurrencia optimista en el Entity Framework. Para hacer bien claros estos pasos, vamos a usar una instancia en FireFox y la otra en Internet Explorer. La primera acción la hacemos en la instancia de Firefox, de donde solicitamos el registro del consultor para modificarlo. Como podemos ver, vamos a cambiarle el nombre al consultor a Luis Diego Rojas Méndez 
Pero antes de que yo haga clic en guardar desde la sesión de internet Explorer solicito el registro para editar y le cambio el nombre de la siguiente forma.
Inmediatamente le doy clic a guardar y el cambio se guarda en la base de datos.
El problema es que el registro todavía se esta editando en la sesión de Firefox, por lo que cuando se guarda el registro modificado desde este navegador vamos a sobre escribir el valor escrito desde la sesión de IE9.
Si editamos el registro desde el IE9 nos vamos a llevar la sorpresa que los cambios hechos en esta sesión ya no están presentes.
Como vemos en el ejemplo anterior, el Entity Framework de salida ofrece solamente concurrencia optimista lo cual puede generar problemas en aplicaciones de tránsito muy alto.
En el próximo post vamos a buscar una solución a este problema.
1 comentario:
Me pareció muy interesante esta entrada. Estoy esperando la segunda parte, me pregunto cual es la mejor manera de bloquear un registra para que solo pueda editarlo una persona a la vez y nadie pierda información. He visto que usan un TimeSpan pero no se cual es la forma correcta de hacerlo
Publicar un comentario