Come ORM gestisce le operazioni CRUD nell'ambiente multi-thread

6

Supponiamo di avere un codice che recupera un oggetto e lo modifica e lo invia tramite qualsiasi ORM da un'applicazione web. Di seguito è riportato lo pseudo codice:

Prima richiesta

var objCust = _dbContext.Customers.Where(c=>c.CustomerId == "ALFKI").SingleOrDefault();
objCust.Address ="test address 1";
//and add some orders
_dbContext.SubmitChanges(); 

Seconda richiesta simultanea

var objCategory = _dbContext.Categories.Where(c=>c.CategoryId == 1).SingleOrDefault();
objCategoryName = "test name";
_dbContext.SubmitChanges();

In che modo la prima richiesta rileva solo le modifiche apportate ai clienti e invia le modifiche. Esiste un meccanismo integrato in ORM per tenere traccia delle modifiche alle entità per thread o richiesta.

    
posta Sunny 22.02.2013 - 19:58
fonte

3 risposte

1

La maggior parte degli O / RM non sono thread-safe. Quando si utilizza un O / RM in un'app Web, la pratica comune è creare un UnitOfWork per richiesta che è legato al thread di quella richiesta. Un'altra opzione è di esporre UnitOfWork come variabile [ThreadStatic]. E infine, ci sono alcuni contenitori di Iniezione di Dipendenza che ti permetteranno di legare la durata di un oggetto (ad esempio un UnitOfWork) a un thread.

    
risposta data 22.02.2013 - 22:48
fonte
0

L'ORM non gestisce (sempre) la transazione. Alla fine della giornata, la transazione sarà gestita dalle garanzie ACID del tuo database mentre l'ORM agirà semplicemente come un livello di comunicazione con il tuo database.

Detto questo, alcuni ORM hanno il caching incorporato e altre tecniche più complesse nei tentativi di evitare il database tranne quando necessario per ridurre il carico sul database. In queste forme di ORM è necessaria in certa misura la gestione della transazione, e la tecnica sarà la stessa utilizzata da qualsiasi applicazione multi-thread per la gestione delle transazioni: stato condiviso con blocchi / semafori / segnali / mutex laddove necessario all'interno dell'ORM. In alternativa potrebbero mancare questi blocchi e semplicemente non essere thread-safe per determinati scenari, ma devo pensare che uno sviluppatore di ORM sarà abbastanza esperto da essere appassionato di questi scenari e concentrarsi sulla sicurezza dei thread.

Nota Dico questo in riferimento ai linguaggi OO in stile Java / C # in cui il blocco è la tecnica necessaria per le garanzie di sicurezza multithreading, ma riconosco che altri tipi di linguaggi utilizzano tecniche lockless.

    
risposta data 22.02.2013 - 20:23
fonte
0

ORM tiene traccia delle modifiche per oggetto sessione non per richiesta / thread. Quando dico sessione intendo _dbContext nel tuo esempio. Nelle applicazioni Web è pratica comune creare un oggetto di sessione per richiesta web.

Quindi, se entrambe le richieste sono separate, nessuna di _dbContexts ne conosce altre. Nel tuo esempio ci saranno due aggiornamenti inviati al database.

    
risposta data 22.02.2013 - 22:55
fonte

Leggi altre domande sui tag