net C# lock-Anweisung in der Datenzugriffsschicht

Question

sah ich einen Code, in dem sie die Datenzugriffsschicht wie dieses:

public class CustomerDA{ 

    private static readonly object _sync = new object(); 
    private static readonly CustomerDA _mutex = new CustomerDA(); 

    private CustomerDA(){ 
    } 

    public CustomerDA GetInstance(){  

     lock(_sync){  
      return _mutex;   
     }  
    } 

    public DataSet GetCustomers(){ 
     //database SELECT 
     //return a DataSet 
    } 

    public int UpdateCustomer(some parameters){ 

     //update some user 
    } 

} 


public class CustomerBO{ 

    public DataSet GetCustomers(){ 

     //some bussiness logic 
     return CustomerDA.GetInstance().GetCustomers(); 
    } 
} 

ich es verwenden, aber anfangen zu denken ... „und was ist, wenn bauen musste eine Facebook-ähnliche Anwendung, wo es Hunderttausende von gleichzeitigen Benutzern gibt? würde ich jeden Benutzer daran hindern, seine Sachen zu machen, bis der vorherige Benutzer seine Datenbank-Sachen beendet? und für die Update-Methode, ist es nützlich, THREADS in der App zu sperren, wenn Datenbank Engines verwalten bereits Parallelität auf Datenbankserverebene? "

Dann begann ich über das Verschieben der Sperre zu den GetCustomers und UpdateCustomer Methoden nachzudenken, aber denken Sie noch einmal: "Ist es überhaupt nützlich?"

bearbeiten am Januar 03:

Sie alles in Ordnung sind, verpasste ich die "statische" Schlüsselwort in der "GetInstance" -Methode.

Anther Sache: Ich war in der Idee, dass kein Thread auf die Variable _mutex zugreifen konnte, wenn ein anderer Thread in der gleichen Datenzugriffsklasse arbeiten würde. Ich meine, ich dachte, seit die _mutex-Variable von innerhalb der Lock-Anweisung zurückgegeben wird, konnte kein Thread auf die _mutex zugreifen, bis die ";" wurde im folgenden Satz erreicht:

return CustomerDA.GetInstance().GetCustomer();

Nach einiger Verfolgung tun, merke ich, ich die falsche Annahme machte. Könnten Sie bitte bestätigen, dass ich die falsche Annahme gemacht habe?

So ... Kann ich sicher sagen, dass meine Datenzugriffsebene keine Sperranweisung benötigt (selbst bei INSERT, UPDATE, DELETE) und dass es keine Rolle spielt, ob Methoden in meinem DataAccess statische oder Instanzmethoden sind?

Thanks again ... Ihre Kommentare sind mir so nützlich

Answer 1

Das Schloss in diesem Code völlig sinnlos ist. Es sperrt den Code, der einen Wert zurückgibt, der sich nie ändert, daher gibt es keinen Grund, eine Sperre dort zu haben. Der Zweck der Sperre im Code besteht darin, das Objekt zu einem Singleton zu machen, aber da es keine faule Initialisierung verwendet, wird die Sperre überhaupt nicht benötigt.

Die Datenzugriffsschicht als Singleton zu erstellen, ist eine sehr schlechte Idee, dh immer nur ein Thread kann auf die Datenbank zugreifen. Es bedeutet auch, dass die Methoden in der Klasse Sperren verwenden müssen, um sicherzustellen, dass immer nur ein Thread auf die Datenbank zugreift oder der Code nicht ordnungsgemäß funktioniert.

Stattdessen sollte jeder Thread eine eigene Instanz der Datenzugriffsebene mit einer eigenen Verbindung zur Datenbank erhalten. Auf diese Weise kümmert sich die Datenbank um die Gleichzeitigkeitsprobleme, und die Theads müssen überhaupt nicht sperren.

Answer 2

Stellen Sie Ihr Schloss dort ein, wo es benötigt wird, also wo gleichzeitige Zugriffe stattfinden. Fügen Sie nur so viel Code in den Lock/Critical Section ein, wie Sie wirklich benötigen.

Das GetInstance sollte nicht statisch sein?

Der folgende Pseudocode erläutert, wie GetInstance arbeitet:

1. LOCK
2. rval = _mutex
3. UNLOCK
4. Return rval

_mutex nur lesbar ist, bezieht sich auf eine nicht- Null-Objekt, so dass es nicht geändert werden kann, warum sperren?

Wenn Ihre Datenbank Gleichzeitigkeitsverwaltung bietet, aber in Ihrem Programm erstellen Sie zwei Threads schreiben die gleichen Daten in der gleichen Zeit in Ihrer eigenen Domäne, während Sie auf die Daten warten, Wie könnte Ihre Datenbank helfen?