««« | »»»
OR Mappers: il caching
Fra i vantaggi che sono solitamente ascritti agli ORM c’è il caching. Si sfrutta la possibilità di creare in memoria una rappresentazione persistente di righe nel database, sotto forma di un grafo di oggetti, per evitare di dover andare a ripescare dal database medesimo i dati ogni volta che serve.
È un’idea sensata, ovviamente, ma credo che abbia un uso più limitato di quanto si pensi, soprattutto in tempi come questi fatti di architetture distribuite, dove la cache può diventare un’arma a doppio taglio.
Ad esempio, quando seguivo con più attenzione la mailing list di WebObjects c’era spesso una domanda ricorrente “Ho n istanze della stessa applicazione, collegate allo stesso database; come faccio a ‘far vedere’ le modifiche dell’istanza A all’istanza B?”
Per risolvere questo problema nel tempo sono state sviluppate diverse soluzioni, l’ultima di cui sono a conoscenza è composta da er.extensions.remoteSynchronizer e er.jgroups (che usa, appunto, JGroups).
La complessità aumenta considerevolmente e abbiamo comunque risolto solo una parte del problema, visto che se un processo aggiorna il database al di fuori del contesto delle applicazioni A e B le loro cache risultano comunque invalidate.
Inoltre, il problema potrebbe essere considerato risolto solo se ci limitiamo a sistemi tradizionali client/server, ma su web cambia tutto: è un’architettura fondamentalmente stateless, dove le cache intermedie non vanno molto d’accordo con questa caratteristica (un’altra manifestazione dell’end-to-end argument).
Se aggiungiamo questo parametro al calcolo dei costi/benefici ci accorgiamo che il vantaggio del caching risulta molto più ambiguo.
Per proseguire
Commenti e trackback sono disabilitati.