Le funzionalità che distinguono Microsoft Velocity da altri cache frameworks esistenti sono molteplici. La Cache di ASP.Net e il Caching Application Block di Enterprise Library, offrono un ricco set di funzionalità e vantano una presenza di lunga data rispetto a Velocity, sono però entrambi limitati ad un unico appdomain e allo stesso processo dell’applicazione che ne fa uso, come illustrato nel primo post di questa serie.
Le funzionalità dei 3 cache framework citati, sono state raggruppate e messe a confronto in questa tabella comparativa:
Le prime due features, trattate in questo post sono le Regions e i Tags:
Regions & Tags
Quando si dispone di un cluster, i cui step di installazione necessari sono stati illustrati nel precedente post, è possibile utilizzare già da subito la cache di default. Una NamedCache chiamata “Default” viene creata in fase di installazione. Per creare invece una NamedCache personalizzata, con dei parametri specifici, si utilizza il comando powershell new-Cache, meglio descritto nella documentazione.
Le Region possono essere create solo a runtime ed attualmente non è possibile testarne l’esistenza, ma bisogna gestire l’eccezione lato client in fase di creazione della stessa, come dimostrato di seguito.
Quando si inserisce un oggetto nella cache, mediante il metodo PUT ma senza usare le Region, non vi è certezza circa quale cache server conterrà lo stesso. In seguito al caricamento nella cache di un insieme di 1000 oggetti, questi saranno distribuiti nella memoria di tutti i server appartenenti al cluster, in modo da ottimizzarne l’utilizzo delle risorse.
Per reperire successivamente un oggetto, sarà sufficiente conoscerne la chiave e utilizzare il metodo GET.
Una namedCache (che ricordiamo, abbraccia l’intero cluster) è il contenitore principale per i nostri oggetti, può essere diviso in Regions più o meno come un Database è organizzato in Tabelle. Quando ad esempio in una namedCache “Catalog” viene creata una Region “Televisions”, è possibile memorizzarvi un sottoinsieme di oggetti logicamente distinto. L’utilizzo delle RegionAPI, rispetto alle Region-less API (parliamo degli overload differenti dei metodi PUT e GET) esclude la logica di distribuzione degli oggetti sull’intero cluster, confinandoli su di un unico server, lo stesso dove è stata creata la Region.
Quando si caricano gli oggetti utilizzando il metoto PUT, in una Region, è possibile etichettarli con uno o più Tag (DataCacheTag), come dimostrato in questo esempio:
Usare le Region significa rinunciare alla scalabilità ottenuta dalla distribuzione degli oggetti su tutto il cluster, in favore di funzionalità di ricerca aggiuntive, che consentono ad esempio di:
- reperire gli oggetti contenuti in una Region con una sola istruzione(senza conoscerne la chiave/ID)
- reperire gli oggetti con uno specifico Tag
- reperire gli oggetti con tutti i Tags specificati
- reperire gli oggetti con almeno uno dei Tags specificati:
Ecco alcuni esempi di ricerca in una Region con l’ausilio dei Tags:
