Comment totalement verrouiller une ligne dans Entity Framework

Je suis en train de travailler à une situation où nous avons affaire avec des transactions d'argent.

Par exemple, j'ai une table d'utilisateurs de portefeuilles, avec leur solde en ligne.

UserId; Wallet Id; Balance

Maintenant dans notre site web et de services web, chaque fois qu'un certain transaction se produit, nous avons besoin de:

  1. vérifiez qu'il y a suffisamment de fonds disponibles pour effectuer cette opération:
  2. déduire le coût de l'opération à partir de la balance.

Comment et quelle est la bonne façon d'aller sur le verrouillage de ligne /de l'entité pour toute la durée de ma transaction?

De ce que j'ai lu il y a quelques solutions où EF est la marque d'une entité, puis compare cette marque lorsqu'il enregistre de nouveau à la DB, cependant, que faut-il faire quand un autre utilisateur /programme a déjà édité le montant?

Puis-je réaliser cela avec EF? Dans la négative, quelles autres options s'offrent à moi?

Serait d'appeler une procédure stockée permettent éventuellement de pour moi pour verrouiller la ligne correctement de sorte que personne d'autre ne peut accéder à cette ligne dans le SQL Server tandis que le programme a un verrou sur elle?

OriginalL'auteur Zapnologica | 2014-11-18

  1. 9

    EF n'a pas intégré dans le mécanisme de verrouillage, vous aurait probablement besoin d'utiliser des requêtes comme

    using (var scope = new TransactionScope(...))
{
    using (var context = new YourContext(...))
    {
        var wallet = 
            context.ExecuteStoreQuery<UserWallet>("SELECT UserId, WalletId, Balance FROM UserWallets WITH (UPDLOCK) WHERE ...");

        //your logic

        scope.Complete();
    }
}

    OriginalL'auteur Max Brodin

  2. 4

    Le point de l'ensemble d'une base de données transactionnelle est que le consommateur des données détermine comment isolés de leur point de vue sur les données devraient être.

    Indépendamment de savoir si votre transaction est sérialisé quelqu'un d'autre peut effectuer une lecture sale sur les mêmes données que vous venez de modifier, mais n'a pas commis.

    Vous devez tout d'abord vous préoccuper de l'intégrité de votre point de vue et ensuite seulement accepter une dégradation de la qualité de ce point de vue pour améliorer les performances du système où vous êtes sûr qu'il est nécessaire.

    Envelopper tout dans un TransactionScope avec Serialized niveau d'isolation et vous personnellement ne peut pas vraiment se tromper. De baisser le niveau d'isolation quand vous voyez qu'elle est vraiment nécessaire (c'est à dire quand les choses sont parfois incorrectes est OK).

    Quelqu'un demande à ce sujet ici: SQL Server: la prévention des lectures incorrectes dans une procédure stockée

    Ce qui est important à propos de SERIALIZABLE est qu'il est assez fiable de la façon d'obtenir que-si un seul thread d'exécution. Corriger automatiquement.
    Oui; c'est pourquoi il est le meilleur endroit pour commencer! Démarrer à partir d'une sécurité absolue et seulement s'écarter, si nécessaire, et après une bonne compréhension des conséquences.

    OriginalL'auteur briantyler

  3. 4

    vous pouvez définir la isolationlevel sur la transaction dans le cadre de l'Entité pour s'assurer que personne d'autre peut le changer:

    YourDataContext.Database.BeginTransaction(IsolationLevel.RepeatableRead)

    RepeatableRead
    Résumé:
    Les verrous sont placés sur toutes les données utilisées dans une requête, empêchant les autres utilisateurs de mettre à jour les données. Empêche les lectures non reproductibles mais fantôme lignes sont toujours possibles.

    OriginalL'auteur jen b