Драстични разлики, които може да очаквате, ако кеширате това, което е добре да се кешира и избягвате кеширането на данни, които изобщо не трябва да се кешират. Както красотата е в очите на гледащия, така е и с изпълнението. Ето няколко аспекта, които трябва да имате предвид, когато използвате хибернация AS второ ниво на кеш доставчик:
Без персонализирана сериализация – интензивна памет
Ако използвате кеширане на второ ниво, няма да можете да използвате рамки за бърза сериализация като Kryo и ще трябва да се придържате към java serializable, което е гадно.
Освен това за всеки тип обект ще имате отделен регион и във всеки регион ще имате запис за всеки ключ на всеки обект. По отношение на ефективността на паметта това е неефективно.
Липсва възможност за съхраняване и разпространение на богати обекти
Повечето от съвременните кешове също предлагат функционалност на изчислителна мрежа, като вашите обекти са фрагментирани на много малки парчета, намаляват способността ви да изпълнявате разпределени задачи с гарантирано съвместно местоположение на данни. Това зависи малко от доставчика на Grid, но за мнозина би било ограничение.
Под оптимална производителност
В зависимост от това каква производителност ви е необходима и какъв тип приложение използвате, използването на кеша на второ ниво на хибернация може да бъде добър или лош избор. Добро от гледна точка на това, че е plug and play..." вид..." лошо, защото никога няма да изстискате производителността, която бихте получили. Освен това проектирането на богати модели означава повече предварителна работа и повече OOP.
Ограничени възможности за заявки В самия кеш
Това зависи от доставчика на кеш паметта, но някои от доставчиците наистина не са добри да правят JOIN с клауза Where, различна от идентификатора. Ако се опитате да изградите и индекс на паметта за заявка за Hazelcast, например, ще видите какво имам предвид.
