Problemas de concurrencia con múltiples transacciones de bases de datos independientes?

Question

¿Cómo resolvería el problema de concurrencia con el siguiente código? En este ejemplo, nos gustaría saber por qué el usuario ha fallado la autenticación. El problema es que este código hace dos llamadas separadas a la base de datos, pero nos gustaría que todo el método ocurra dentro de una transacción conceptual. Específicamente estamos interesados ​​en isolation. No queremos que las escrituras simultáneas durante la ejecución de este método afecten nuestras lecturas antes de que hayamos determinado el motivo del error de autenticación.

Algunas soluciones vienen a la mente: Thread Locking, TransactionScope y Optimistic Locking. Realmente me gusta la idea de Optimistic Locking, ya que creo que los conflictos son raros, pero no hay nada integrado en .NET para hacer esto, ¿verdad?

Además, ¿hay algo de lo que DE VERDAD estar preocupado en este caso? ¿Cuándo es importante tener en cuenta los problemas de concurrencia y cuándo no? ¿Qué debe considerarse al implementar una solución? ¿Actuación? La duración del bloqueo? ¿Cuán probables son los conflictos?

Editar: Después de revisar respuesta Aristos', creo que lo que estoy realmente después es algún tipo de nivel de aislamiento 'snapshot' para el método de autenticación.

public MembershipStatus Authenticate(string username, string password) 
    { 
     MembershipUser user = Membership.GetUser(username); 
     if (user == null) 
     { 
      // user did not exist as of Membership.GetUser 
      return MembershipStatus.InvalidUsername; 
     } 

     if (user.IsLockedOut) 
     { 
      // user was locked out as of Membership.GetUser 
      return MembershipStatus.AccountLockedOut; 
     } 

     if (Membership.ValidateUser(username, password)) 
     { 
      // user was valid as of Membership.ValidateUser 
      return MembershipStatus.Valid; 
     } 

     // user was not valid as of Membership.ValidateUser BUT we don't really 
     // know why because we don't have ISOLATION. The user's status may have changed 
     // between the call to Membership.GetUser and Membership.ValidateUser. 
     return MembershipStatus.InvalidPassword; 
    } 

Answer 1

Basado en mi lectura here y here, parece como un System.Transactions.TransactionScope envolver su método de toda debe dar de alta automáticamente las llamadas de base de datos en una transacción común, lo que resulta en seguridad transaccional en todo el alcance de la transacción.

Lo que quiere hacer algo como esto:

public MembershipStatus Authenticate(string username, string password) 
{ 
    using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required, new TransactionOptions { IsolationLevel = IsolationLevel.Snapshot })) 
    { 
    MembershipUser user = Membership.GetUser(username); 
     if (user == null) 
     { 
      // user did not exist as of Membership.GetUser 
      return MembershipStatus.InvalidUsername; 
     } 

     if (user.IsLockedOut) 
     { 
      // user was locked out as of Membership.GetUser 
      return MembershipStatus.AccountLockedOut; 
     } 

     if (Membership.ValidateUser(username, password)) 
     { 
      // user was valid as of Membership.ValidateUser 
      return MembershipStatus.Valid; 
     } 

     // user was not valid as of Membership.ValidateUser BUT we don't really 
     // know why because we don't have ISOLATION. The user's status may have changed 
     // between the call to Membership.GetUser and Membership.ValidateUser. 
     return MembershipStatus.InvalidPassword; 
    } 
} 

Answer 2

voy a utilizar mutex usando el nombre como parámetro de bloqueo, por lo que sólo el mismo usuario puede puede bloquear por un tiempo. Esto para mí es más seguro para una computadora porque con mutex puedo capturar todos los hilos posibles de diferentes grupos o llamadas web.

public MembershipStatus AuthenticateLock(string username, string password) 
{ 
    if(string.IsNullOrEmpty(username)) 
     return MembershipStatus.InvalidUsername; 

    // TODO: Here you must check and clear for non valid characters on mutex name 
    using (var mutex = new Mutex (false, username)) 
    { 
     // possible lock and wait, more than 16 seconds and the user can go... 
     mutex.WaitOne (TimeSpan.FromSeconds(16), false); 

     // here I call your function anyway ! and what ever done... 
     // at least I get a result 
     return Authenticate(username, password) 
    } 
} 

Más comentarios: Tanto Membership.ValidateUser y Membership.GetUser Realizar una llamada a la base de datos.

Pero si se utiliza la sesión asp.net estándar de las páginas que componen este llamadas y afectan a este parámetros, entonces el página muestra todos bloqueo listo el otro, así que creo que no hay ninguna posibilidad de necesitar este llamada mutex Porque el bloqueo de la sesión es suficiente para sincronizar y esta parte. Recuerdo que la sesión está bloqueando la página desde el principio hasta el final para todos los usuarios.

Acerca de bloqueo de sesión: Replacing ASP.Net's session entirely

jQuery Ajax calls to web service seem to be synchronous