Differenze drastiche che potresti aspettarti se metti nella cache ciò che è bene essere memorizzato nella cache ed evita di memorizzare nella cache i dati che non dovrebbero essere affatto memorizzati nella cache. Come la bellezza è negli occhi di chi guarda, lo stesso vale per la performance. Ecco alcuni aspetti che dovresti tenere a mente quando usi il provider di cache di secondo livello di ibernazione AS:
Nessuna serializzazione personalizzata - Uso intensivo di memoria
Se utilizzi la memorizzazione nella cache di secondo livello, non saresti in grado di utilizzare framework di serializzazione veloce come Kryo e dovrai attenerti a java serializzabile, il che fa schifo.
Inoltre per ogni tipo di entità avrai una regione separata e all'interno di ogni regione avrai una voce per ogni chiave di ciascuna entità. In termini di efficienza della memoria, questo è inefficiente.
Manca la capacità di archiviare e distribuire oggetti avanzati
La maggior parte delle moderne cache presenta anche funzionalità di griglia di calcolo in cui i tuoi oggetti frammentati in molti piccoli pezzi riducono la tua capacità di eseguire attività distribuite con co-locazione dei dati garantita. Dipende un po' dal provider della rete, ma per molti sarebbe una limitazione.
Rendimento non ottimale
A seconda delle prestazioni necessarie e del tipo di applicazione che stai utilizzando utilizzando la cache di secondo livello di ibernazione potrebbe essere una buona o una cattiva scelta. Buono in termini di plug and play...." un po'..." pessimo perché non spremerai mai le prestazioni che avresti ottenuto. Inoltre, la progettazione di modelli ricchi significa più lavoro iniziale e più OOP.
Capacità di query limitate nella cache stessa
Dipende dal provider di cache, ma alcuni provider non sono in grado di eseguire JOIN con clausola Where diversa dall'ID. Se provi a costruire e in memory index per una query su Hazelcast, ad esempio, vedrai cosa intendo.
