DataBindings automágicos (II): una solución quiero!!!!

Bueno, seguimos con el tema, después de la presentación del problema voy a intentar ofrecer una solución aceptable y rápida.

Está claro que el método que guarda los registros no hace lo que nos gustaría que hiciese, así que vamos a cambiarlo un poco. Nos vamos al método pedidoBindingNavigatorSaveItem_Click y añadimos el siguente código:

private void pedidoBindingNavigatorSaveItem_Click(object sender, EventArgs e)
{

this.Validate();

this.pedidoBindingSource.EndEdit();

this.pedidoTableAdapter.Update(this.dataSet1.Pedido);

// Después de hacer el Update, llamamos al método Fill para que
// recargue los registros de la tabla de Pedido

this.pedidoTableAdapter.Fill(this.dataSet1.Pedido);


// Obtenemos el identificador del último registro que haya en el Pedido del Dataset
// que se debería corresponder con el que acabamos de insertar

int id;
id = (int)this.dataSet1.Pedido.Rows[this.dataSet1.Pedido.Rows.Count - 1]["id"];


// Ahora vamos a las líneas de detalle y le cambiamos el idPedido sólo a las
// que acabamos de añadir

foreach (System.Data.DataRow row in this.dataSet1.Detalle_Pedido.Rows)
{

if (row.RowState == DataRowState.Added)
row["idPedido"] = id;

}


this.detalle_PedidoBindingSource.EndEdit();


// Forzamos el Update

this.detalle_PedidoTableAdapter.Update(this.dataSet1.Detalle_Pedido);


// y nos volvemos a traer los registros de Detalle_Pedido, con lo que tendremos
// los identificadores actualizados

this.detalle_PedidoTableAdapter.Fill(this.dataSet1.Detalle_Pedido);


// Nos movemos al último registro de la cabecera
// que debería ser el que acabamos de añadir

this.pedidoBindingSource.MoveLast();

this.Refresh();

}


¿Qué problemas plantea esta solución?

Para empezar, es una solución para salir del paso (una ñapa como una casa :P), y está claro que no se puede tomar como definitiva. En entornos en los que la concurrencia sea un problema hay que usar técnicas de concurrencia y bloqueos sin remisión con lo que en vez de un problema pasamos a tener 2, la concurrencia y los interbloqueos (deadlocks y similares).

Segundo, el principal problema es que estamos suponiendo que el último registro es efectivamente el nuestro, pero eso puede ser cierto o no. Tendríamos que tener la certeza absoluta de que es así, lo que implicaría hacer consultas sobre la base de datos o bloquear registros.

Y para acabar, el último que guarda en este escenario de concurrencia tiene constancia de todos los registros en cuanto guarda, pero el primero que guarde no obtiene todos los registros hasta que introduzca uno nuevo. Esto puede ser problemático o no, dependerá de nuestro escenario particular.


Conclusiones

- Las cosas fáciles no suelen tener en cuenta los problemas complejos, que suelen ser con los que nos tenemos que pelear en la vida real. Hacer databinding con drag-and-drop están muy bien para hacer pequeños proyectos, pero cuando entra en juego la concurrencia tenemos que saber qué es lo que hay por debajo, y eso sólo se consigue si tenemos muy claro cómo trabaja ADO.NET y sus clases.

- No te preocupes, que lo que te está pasando seguro que le pasó a un millón de programadores antes y casi todos encontraron una solución. Sólo te queda encontrar la tuya, que dependerá de tu problema concreto mucho más de lo que te imaginas.

- Vamos, que no hay una solución definitiva para el tema del acceso a datos y mucho menos el de la concurrencia. Yo personalmente recomiendo usar un ORM para que mapee el modelo de base de datos en clases, que los hay muchos y muy buenos por ahí.

Eso sí, a la espera que el Entity Framework sea lo que todos esperamos que sea ;)

DataBindings automágicos (I)

(No, no me he equivocado quería escribir autoMÁGICOS no automáticos :P el porqué ya ser verá en el post)

Hace un par de semanas me mandó un mail un lector del blog (Germán) comentándome una duda con el uso de Datasets tipados como origen de datos en Windows Forms.

Dado que ya me había pasado algo similar en algún proyecto en el que trabajé pero del que no recuerdo cómo lo solucionamos, decidí ponerme manos a la obra para hacer un proyecto que tenga la problemática que me planteó Germán y tratar de encontrar una solución óptima. Y como le comenté a Germán, lo pongo aquí para que le sirva a más gente ;) Vamos a empezar:

Tenemos una base de datos a la que llamaré PRUEBAS, con únicamente 2 tablas: Pedido y DetallePedido, con el siguiente esquema:

Pedido
id -Identity PRIMARY_KEY
Descripcion -Varchar(10)

DetallePedido
idDetalle - Identity PRIMARY_KEY
idPedido - Int
Cantidad - Int
Precio - Float

Típicas tablas maestro-detalle, relacionadas por Pedido.id – DetallePedido.idPedido


Creamos un proyecto Windows Form en Visual Studio 2005, y añadimos un Dataset donde agregamos las 2 tablas, que nos quedará de la siguiente forma:

Ahora nos vamos al formulario, y desde el explorador de Origenes de Datos, arrastramos los campos de la tabla Pedidos y los relacionados de DetallesPedido (Atención: tiene que ser el que cuelga de Pedido para que nos mantenga la relación)

Con lo que el formulario nos quedará más o menos así:

Ahora nos vamos a código y buscamos el evento pedidoBindingNavigatorSaveItem_Click que es el que se produce cuando presionamos el botón de Guardar Cambios, y añadimos las 2 líneas en rojo para que guarde también las líneas de detalle:

private void pedidoBindingNavigatorSaveItem_Click(object sender, EventArgs e)
{
this.Validate();
this.pedidoBindingSource.EndEdit();
this.pedidoTableAdapter.Update(this.dataSet1.Pedido);
this.detalle_PedidoBindingSource.EndEdit();
this.detalle_PedidoTableAdapter.Update(this.dataSet1.Detalle_Pedido);
}

Si lo probamos debería funcionar perfectamente, permitiendo movernos entre registros, agregar nuevos pedidos y sus líneas de detalle correspondientes. Ahora viene el problema que nos plantea Germán, ¿y si hay 2 usuarios añadiendo pedidos a la vez?

Pues vamos a probarlo, compilamos, arrancamos 2 veces el ejecutable y creamos un nuevo pedido en cada instancia. ¿Qué sucede? Como es normal asigna un valor al campo id del pedido, que obtiene de sumarle 1 al último valor más grande que exista en la tabla ese momento (ojo: no es el valor que le corresponda al IDENTITY) con lo que nos dará el mismo valor para las 2 instancias.

No vamos a hacer nada más por ahora, guardamos y vemos que pasa.

Como es normal nos ha actualizado el id del pedido con el valor que le ha asignado en la tabla de la base de datos. Bien, es el comportamiento normal y esperado.

Vale, ahora vamos a introducir líneas en estos 2 pedidos que acabamos de guardar:

Como en el caso de las cabeceras de pedido, nos asigna un valor al campo idDetalle, que vuelve a ser el valor máximo del campo en la tabla sumándole 1, con lo que vuelve a ser el mismo valor para las 2 instancias. Guardamos y nos asigna el valor que le corresponde en la tabla.

Vale, todo va bien, hemos añadido una cabecera y una línea y no hay ningún problema, ¿seguro que no hay problemas?

Vamos a hacer lo mismo que antes pero cambiando un poco la forma de hacerlo, ahora vamos a guardar después de añadir la línea de detalle, a ver qué pasa.

Vaya sorpresa, nos ha desaparecido la línea del 2º pedido que guardemos, ahora si nos movemos por los registros esa línea no aparece en ninguna de las 2 instancias, pero si nos vamos a la tabla veremos que está con el identificador que le asignó a la primera instancia que se guardó.

Si cerramos los formularios y volvemos a abrirlos nos encontraremos un pedido con 2 líneas y otro sin líneas. Esto se debe a que al asignar el valor del identificador a las cabeceras también lo hace con las líneas, pero al guardar no actualiza el identificador del pedido en las líneas, con lo que se queda el que tenía en un principio ... ups, vaya lío que hemos montado, ¿no?

Bueno, creo que ya se puede ver por donde van los tiros: ¿nos fiamos o no nos fiamos del código generado automáticamente al arrastar elementos desde los orígenes de datos?

Como este post ya es bastante largo, os presentaré más cosas sobre DataBinding, más problemas y cómo solucionarlos en un próximo post, permanecer atentos al blog :)

Bloqueo exclusivo de objetos en C# y VB.NET

Leyendo el libro Microsoft Windows Workflow Foundation Step by Step escrito por Kenn Scribner me encontré con una instrucción para realizar un bloqueo de exclusión mutua en objetos. Posiblemente esto sea a lo que se refiere Ciro Franz el comentario que me hizo en mi blog en BcnGeeks, y como me quedaría un comentario muy largo, prefiero hacer un post.

C# (lock)

Vamos a ver de qué se trata, en C# se realiza con la instrucción lock() que según MSDN: marca un bloque de instrucciones como una sección crucial, para lo cual utiliza el bloqueo de exclusión mutua de un objeto, la ejecución de una instrucción y, posteriormente, la liberación del bloqueo.

Vaya, otra definición extraña de MSDN, pero si seguimos leyendo lo aclaran un poco más: La instrucción lock permite garantizar que un subproceso no va a entrar en una sección crucial de código mientras otro subproceso ya se encuentre en ella. Si otro subproceso intenta entrar en un código bloqueado, esperará, o se bloqueará, hasta que el objeto se libere.

Y esto no es ni más ni menos que una forma de control de concurrencia sobre un objeto, pero lo más interesante es la forma de usarlo, esta instrucción contiene un bloque de código que se ejecuta mientras el exista el bloqueo. Mejor me explico con código:

Object objeto;

lock(objeto)
{
//codigo....
//codigo....
}

Si otro proceso intenta ejecutar la instrucción lock(), y el objeto está bloqueado, tendrá que esperar a que se acabe de ejecutar todo el bloque de código.

Vale, vamos a poner un ejemplo práctico en el que no hay bloqueos, para luego demostrar como funciona la instrucción lock. Como casi siempre, será una aplicación de consola en C#, a la que añadimos el siguiente código:

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;

namespace PruebaLock
{
class Program
{
static void Main(string[] args)
{
//Declaramos 10 hilos que ejecuten en método EjecutarMetodoEstatico
Thread[] threads = new Thread[10];
for (int i = 0; i < 10; i++)
{
Thread t = new Thread(new ThreadStart(ClaseEstatica.EjecutarMetodoEstatico));
threads[i] = t;
}

//Ejecutamos los hilos
for (int i = 0; i < 10; i++)
{
threads[i].Start();
}

//Esperamos a que se pulse una tecla para finalizar
Console.WriteLine("Pulse una tecla para salir...");
Console.ReadKey();
}
}

public static class ClaseEstatica
{
public static void EjecutarMetodoEstatico()
{

Console.WriteLine("Ejecutando bloque de código...");
// La instrucción Sleep suspende la ejecución del hilo,
// la utilizo en vez de un bloque de código que tarde
             // 1 segundo en ejecutarse
Thread.Sleep(1000);
Console.WriteLine("Fin bloque de código.");
}
}
}

Ejecutamos (F5), y se obtiene este resultado:

Como podemos ver, los objetos se ejecutan en paralelo y finalizan a la vez.

Bien, vamos a probar el bloqueo, cambiamos el código que teníamos antes por este, fijaos en que el bloque en el que está la instrucción Sleep(), empieza con lock(objetoBloqueo):

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;

namespace PruebaLock
{
class Program
{
static void Main(string[] args)
{
//Declaramos 10 hilos que ejecuten en método EjecutarMetodoEstatico
Thread[] threads = new Thread[10];
for (int i = 0; i < 10; i++)
{
Thread t = new Thread(new ThreadStart(ClaseEstatica.EjecutarMetodoEstatico));
threads[i] = t;
}

//Ejecutamos los hilos
for (int i = 0; i < 10; i++)
{
threads[i].Start();
}

//Esperamos a que se pulse una tecla para finalizar
Console.WriteLine("Pulse una tecla para salir...");
Console.ReadKey();
}
}

public static class ClaseEstatica
{
// Declaramos el objeto que se va a bloquear, debe ser private
private static object objetoBloqueo = new object();

public static void EjecutarMetodoEstatico()
{
lock (objetoBloqueo)
{
Console.WriteLine("Ejecutando bloque de código...");
//La instrucción Sleep suspende la ejecución del hilo,
//la utilizo en vez de un bloque de código que tarde 1 segundo en ejecutarse
Thread.Sleep(1000);
}
Console.WriteLine("Fin bloque de código.");
}
}
}

Y el resultado:



La instrucción Console.WriteLine("Pulse una tecla para salir..."); se ejecuta la primera, porque los hilos están ocupados con los bloqueos, y no se ejecuta un hilo hasta que haya acabado el anterior, con lo que ya tenemos montado una especie de control de concurrencia pesimista.


VB.NET (Synclock)

En VB.NET la instrucción que realiza el bloqueo es Synclock() y su uso es idéntico al de lock() de C#, lo curioso es que en MSDN, esté descrita de la siguiente forma: Adquiere un bloqueo exclusivo para un bloque de instrucciones antes de ejecutar el bloque.

Si alguien lo entiende, que me lo explique, porque la definición de lock() es complicada, pero por lo menos se entiende.

Bueno, vamos a olvidarnos de las definiciones de MSDN, y vamos al mismo código de ejemplo pero en VB.NET:

Imports System.Threading

Module Module1

Sub Main()
'Declaramos 10 hilos que ejecuten en método EjecutarMetodoEstatico
Dim threads(10) As Thread
For i As Integer = 0 To 10
Dim t As Thread = New Thread(New ThreadStart(AddressOf ClaseEstatica.EjecutarMetodoEstatico))
threads(i) = t
Next

' Ejecutamos los hilos

For i As Integer = 0 To 10
threads(i).Start()
Next

' Esperamos a que se pulse una tecla para finalizar
Console.WriteLine("Pulse una tecla para salir...")
Console.ReadKey()
End Sub

End Module

Public Class ClaseEstatica

' Declaramos el objeto que se va a bloquear, debe ser private
Private Shared objetoBloqueo As Object = New Object()

Public Shared Sub EjecutarMetodoEstatico()
SyncLock objetoBloqueo

Console.WriteLine("Ejecutando bloque de código...")
' La instrucción Sleep suspende la ejecución del hilo,
' la utilizo en vez de un bloque de código que tarde 1 segundo en ejecutarse
Thread.Sleep(1000)

End SyncLock
Console.WriteLine("Fin bloque de código.")
End Sub
End Class

Si lo ejecutáis, funciona exactamente igual que el ejemplo de C#.


Conclusión

Como siempre alguno se puede preguntar ¿y para qué quiero bloquear el acceso a un bloque de código?

Pues en el libro de Kevin Scribner sirve para hacer una clase singleton que devuelve una única instancia de WorkflowRuntime a todas los procesos que llamen a una clase estática, que es una solución que a mi me parece muy interesante.

Pero está claro que si no estás realizando un proceso multi-hilo, la concurrencia no te debería importar demasiado, pero, a poco que crezca tu aplicación, los hilos serán imprescindibles y el control de concurrencia puede ser muy útil.

Aunque el uso que le deis queda en vuestras manos, o más bien abierto a vuestra imaginación.

Control de concurrencia pesimista en ADO.NET (VB.NET)

Como lo prometido es deuda, aquí esta el código en VB.NET del anterior artículo

Imports System
Imports System.Text
Imports System.Data
Imports System.Data.SqlClient

Namespace BloqueoPesimista

 Module Module1

  Sub Main()
   Dim ds As DataSet = New DataSet()
   Dim conexion As SqlConnection = New SqlConnection()
   Dim transaccion As SqlTransaction
   Dim comando As SqlCommand = New SqlCommand()
   Dim da As SqlDataAdapter = New SqlDataAdapter()

   Console.WriteLine("Pulse una tecla para iniciar...")
   Console.ReadKey()

   Try
    ' La cadena de conexión indica que atacamos a la base de datos Northwind del servidor local
    conexion = New SqlConnection("Data Source=.;Initial Catalog=Northwind;Integrated Security=True")

    comando.Connection = conexion
    comando.CommandType = CommandType.Text

    ' El SELECT tiene un parámetro para evitar SQL Injection
    comando.CommandText = "SELECT ProductID, ProductName FROM Products WITH (Rowlock,Xlock) " & _
           "WHERE ProductID  = @ID"
    comando.Parameters.AddWithValue("@ID", 1)
    da.SelectCommand = comando

    'Abrimos la conexión y ejecutamos en comando
    'Nota: también se puede hacer con la sentencia Using() que nos evita abrir y cerrar la conexión
    conexion.Open()

    ' La transacción no tiene constructor, se crea a partir de la conexión a través de un Class Factory 
    transaccion = conexion.BeginTransaction(IsolationLevel.ReadCommitted)

    ' Una vez creada la transacción la asignamos al comando
    comando.Transaction = transaccion

    ' Ejecutamos el comando mediante el SQLDataAdapter
    da.Fill(ds, "Products")

    ' Mostramos el registro bloqueado
    Console.WriteLine("Registro con ProductID = {0} está bloqueado.", ds.Tables("Products").Rows(0)("ProductID"))

    Console.WriteLine("Pulse una tecla para finalizar el bloqueo...")
    Console.ReadKey()

    ' Finalizamos la transacción, aquí ya se deshace el bloqueo
    transaccion.Rollback()

    ' Cerramos la conexión
    conexion.Close()

   Catch ex As Exception
    If conexion.State <> ConnectionState.Closed Then
     conexion.Close()
    End If

    Console.WriteLine(ex.Message)
    Console.ReadKey()

   End Try

  End Sub

 End Module

End Namespace

Control de concurrencia pesimista con ADO.NET (C#)

Esta es la primera entrada seria del blog, después de la presentación, así que espero que me salga bien.

El tema a tratar es el control pesimista en ADO.NET como solución para la concurrencia entre varios usuarios al acceder a un mismo registro de una tabla. El caso concreto que voy a tratar corresponde a una base de datos SQL Server. Para otro tipo de bases de datos existen otras soluciones.

Para los que no conozcáis como maneja la concurrencia ADO.NET tenéis una introducción en este blog, o en esta entrada de MSDN.

En este post vamos a tratar el caso de la concurrencia pesimista, esto es, cuando un usuario accede a un registro éste quedará bloqueado para los demás usuarios que tengan acceso a la base de datos.

Para que os hagáis una idea de por donde van los tiros, se trata de especificarle a SQL Server que queremos bloquear un registro mientras estamos en una transacción.

¿Cómo se hace?

Vayamos por partes, lo primero que tengo que explicar es que en SQL Server existe una instrucción en la sentencia SELECT para que bloquee un registro cuando lo leemos. Esta instrucción se conoce como Table Hint y lo que hace es indicarle al optimizador de consultas (query optimizer) el método de bloqueo de la tabla o vista.

Por emplo: SELECT * FROM MiTabla WITH(Rowlock, Xlock) WHERE id = 10;

Rowlock -> fuerza el bloqueo de los registros que devuelva la instrucción.
Xlock -> indica que el bloqueo es exclusivo.

Y esta sentencia SELECT la tenemos que iniciar con una transacción abierta. El bloqueo existe mientras la transacción esté en curso, por tanto, hasta que no se finalice la transacción (Commit o Rollback), se salga de su alcance o se cierre la conexión, el bloqueo permanecerá activo. Para que el bloqueo sea efectivo el nivel de asilamiento de la transacción (isolationLevel) puede ser ReadCommitted, ReadUnCommitted, RepetableRead o Serializable, no aceptandose Chaos, ni SnapShot, ni Unspecified.



El código

Seguro que viendo el código lo entenderéis mejor de que va todo esto, así que aquí lo tenéis:

using System;
using System.Collections.Generic;
using System.Text;
using System.Data;
using System.Data.SqlClient;

namespace BloqueoPesimista
{
    class Program
    {
        static void Main(string[] args)
        {

            DataSet ds = new DataSet();
            SqlConnection conexion = new SqlConnection();
            SqlTransaction transaccion;
            SqlCommand comando = new SqlCommand();
            SqlDataAdapter da = new SqlDataAdapter();

            Console.WriteLine("Pulse una tecla para iniciar...");
            Console.ReadKey();

            try
            {

                // La cadena de conexión indica que atacamos a la base de datos Northwind del servidor local
                conexion = new SqlConnection("Data Source=.;Initial Catalog=Northwind;Integrated Security=True");

                comando.Connection = conexion;
                comando.CommandType = CommandType.Text;

                // El SELECT tiene un parámetro para evitar SQL Injection
                comando.CommandText = "SELECT ProductID, ProductName FROM Products WITH (Rowlock,Xlock) " +
                                      "WHERE ProductID  = @ID";
                comando.Parameters.AddWithValue("@ID", 1);
                da.SelectCommand = comando;

                //Abrimos la conexión y ejecutamos en comando
                //Nota: también se puede hacer con la sentencia Using() que nos evita abrir y cerrar la conexión
                conexion.Open();

                // La transacción no tiene constructor, se crea a partir de la conexión a través de un Class Factory
                transaccion = conexion.BeginTransaction(IsolationLevel.ReadCommitted);

                // Una vez creada la transacción la asignamos al comando
                comando.Transaction = transaccion;

                // Ejecutamos el comando mediante el SQLDataAdapter
                da.Fill(ds, "Products");

                // Mostramos el registro bloqueado
                Console.WriteLine("Registro con ProductID = {0} está bloqueado.", ds.Tables["Products"].Rows[0]["ProductID"]);

                Console.WriteLine("Pulse una tecla para finalizar el bloqueo...");
                Console.ReadKey();

                // Finalizamos la transacción, aquí ya se deshace el bloqueo
                transaccion.Rollback();

                // Cerramos la conexión
                conexion.Close();
            }
            catch (Exception e)
            {
                if (conexion.State != ConnectionState.Closed)
                    conexion.Close();

                Console.WriteLine(e.Message);
                Console.ReadKey();
            }
        }
    }
}

Se trata de una aplicación de consola en C#, en un futuro post pondré el código en VB.NET. Así que sólo hay que copiarlo en un proyecto de consola.


Vamos a probarlo

Para poder pobrarlo, hay que Generar el proyecto, con lo que nos creara un fichero .EXE en la carpeta Bin/Debug del proyecto.
Ejecutamos el exe una vez y pulsamos una tecla para que se inicie el bloqueo.







Si volvemos a ejecutar el exe e iniciamos el bloqueo, la aplicación se quedará esperando que se libere el registro.






En cuanto finalicemos la primera ejecución, la segunda podrá acceder al registro y bloquearlo.


Y con esto finalizamos por hoy. Para ser la primera entrada me ha quedado un poco larga, pero espero que pueda ayudar a cualquiera de los que la lean.

Cualquier duda o sugerencia, por favor, en los comentarios.


PD: ¿Es el control de concurrencia pesimista la mejor opción? En absoluto, pero para algún caso en concreto puede ser LA SOLUCIÓN. Queda a vuestro criterio el usarlo o no.