Application
è un datastore che rimane dalla vecchia tecnologia ASP. Ha un unico blocco globale. Quando chiami Application.Lock()
tutti gli accessi all'oggetto Application in tutti i thread sono bloccati.
D'altra parte l'ultimo Cache
oggetto introdotto con ASP.NET consente di utilizzare la propria semantica di blocco. È possibile utilizzare l'istruzione lock
di .NET per garantire l'accesso sicuro ai thread all'oggetto cache mantenendo l'applicazione Web il più possibile parallela. L'istruzione lock
è molto più sicura poiché il blocco è garantito per essere rilasciato quando si esce da un blocco lock
. L'oggetto dell'applicazione non lo garantisce. Cache fornisce anche meccanismi di auto-expire che sono molto più adatti per, beh, una cache. Può anche scadere le chiavi in base a contratti di dipendenza e priorità opzionali che, naturalmente, l'oggetto dell'applicazione non è in grado di contenere.
Non vedo alcun motivo per utilizzare Application
su Cache
oggetto.
Esempio: supponiamo di avere centinaia di elementi nella cache e di avere un singolo elemento che si desidera memorizzare nella cache se non è già presente. Quando si utilizza Application
, si esegue questa operazione:
if(Application["someData"] == null)
{
Application.Lock();
if(Application["someData"] == null)
{
Application["someData"] = getValue(); //a very long time consuming function
}
Application.Unlock();
}
In questo scenario tutti gli accessi all'oggetto Application vengono bloccati anche se sono del tutto irrilevanti. E nel caso in cui getValue()
causi un'eccezione, l'applicazione viene bloccata perché il blocco non viene rilasciato. È necessario avvolgere uno try
.. finally
in giro per assicurarsi che sia sicuro.
D'altra parte quando si utilizza un oggetto Cache
, si esegue questa operazione:
if(Cache["someData"] == null)
{
lock(myLockObject) // or other shared lock for that single value
{
if(Cache["someData"] == null)
{
Cache["someData"] = getValue();
}
}
}
In questo caso solo i blocchi di codice che richiedono l'accesso a myLockObject
avrebbero aspettato. Altri che accedono a Cache
corrono parallelamente bene. E nel caso in cui getValue()
generi un'eccezione, il blocco viene rilasciato senza problemi lasciando che altri thread continuino l'esecuzione.
fonte
2012-04-22 14:59:14
La raccolta Cache è stata resa protetta da thread da Microsoft. Non è richiesto alcun blocco esterno. –
La cache stessa essendo thread-safe garantisce solo l'atomicità e non la coerenza. Guarda il codice di esempio qui sopra. Se non si dispone dell'istruzione 'lock', più thread chiamerebbero' getValue() 'allo stesso tempo, indipendentemente che la cache sia sicura o meno. –
E mi chiedo il motivo dietro il downvote, affermando "questa risposta non è utile". Veramente? –