EhCache е широко използван, чист Java кеш, който може лесно да се интегрира с най-популярните Java рамки, като Spring и Hibernate. Често се смята за най-удобният избор за Java приложения, тъй като може лесно да се интегрира в проекти. В частност:
Накратко, EhCache е чудесен избор за всяко приложение с чиста Java.
Освен това, Пролетни анотации на EhCache позволява безпроблемна интеграция във всяко приложение Spring чрез просто добавяне на анотации към кешируеми методи, без да се променят реализациите на метода.
Докато EhCache предоставя директни, богати API за програмно манипулиране на кеша, тази статия се фокусира главно върху усилване на вашите пролетни приложения по по-малко натрапчив начин с пролетните пояснения на EhCache. Ще създадем пролетен MVC проект и ще внедрим RESTful уеб услуга в Tomcat. След това EhCache ще бъде интегриран към уеб услугата.
Ще демонстрираме EhCache анотации в контекста на примерен проект. Ще създадем a Пролет Уеб услуга, базирана на MVC, хоствана на Tomcat 8 сървър.
Разработих проекта в Eclipse, който може да бъде инсталиран следвайки инструкциите тук .
ръководство за c++
Може да се изтегли последната стабилна версия на Tomcat, Tomcat 8 тук .
Разбира се, тези специфични платформи не са изискване за EhCache; винаги можете да изберете любимите си IDE и сървър.
Наличен е JAR на EhCache Spring Annotations тук . Както виждаме, има две JAR за всяка версия: една със зависимости и една без. Този със зависимости включва също EhCache 2 и Spring 3, които са необходими за работа на анотациите на EhCache. По-лесно е да се настрои, ако изтеглим този със зависимости и го добавим към нашия път на изграждане.
EhCache Spring Annotations също е съвместим с Spring 4, въпреки че трябва да бъде конфигуриран отделно. Не е ясно дали проектът ще поддържа EhCache 3 в близко бъдеще. За тези, които използват или възнамеряват да използват EhCache 3, подходът за анотиране, обсъден в тази статия, не се препоръчва.
И накрая, ще използваме Maven, за да управляваме всичко. Maven се предлага предварително опакована с повечето инсталации на Eclipse, но може и да се получи тук . Spring MVC и EhCache Spring Annotations зависимости могат да се добавят доста лесно, както е показано по-нататък в тази статия.
Ако никога преди не сте създавали пролетен проект, може също да намерите Пост на Стефан Варга по темата информативен.
За тази демонстрация ще създадем основен проект с помощта на Maven архетип maven-archetype-webapp
. Цялостната файлова структура ще изглежда така:
какъв тип llc имам нужда
Създайте директория, src/main/java
, с три пакета: com.toptal.blog
, com.toptal.blog.cache
и com.toptal.blog.service
. Нашият източник на приложение ще отиде в тези пакети, както е описано по-долу.
Нека дефинираме сервлет на Tomcat, наречен „springrest“ в web.xml
:
angularjs валидиране на въвеждане без форма
... springrest org.springframework.web.servlet.DispatcherServlet 1 springrest /*
Освен ако изрично не е посочено друго, Spring MVC DispatcherServlet
ще търси XML конфигурационен файл с име {servlet-name}-servlet.xml
в директорията WEB-INF
. Нека създадем конфигурационен файл, наречен springrest-servlet.xml
. За да активирате методите на процесора Spring процес, анотирани с @RequestMapping
, нека просто добавим към този файл. Също така, нека дефинираме основния пакет за Spring за автоматично сканиране и регистриране на зърна чрез добавяне. springrest-servlet.xml
конфигурацията става:
project.toptal.blog
Сега, когато нашият проект е правилно конфигуриран, нека внедрим прост API за „услуга за съобщения“. В нашия основен пакет, SpringRestControllerWithEhCache.java
, ще добавим @RestController @RequestMapping( '/' ) public class SpringRestControllerWithEhCache { @Autowired MessageService messageService; @RequestMapping( value = '/message/{id}', method = RequestMethod.GET ) public String getMessage( @PathVariable Integer id ) { String message = messageService.getMessage( id ); System.out.println( 'get message ['+message+'] at '+new Date() ); return message; } @RequestMapping( value = '/message/set/{id}/{message}', method = RequestMethod.POST ) public String setMessage( @PathVariable Integer id, @PathVariable String message ) { System.out.println( 'set message ['+message+'] at '+new Date() ); messageService.setMessage( id, message ); return message; } }
, с един метод GET за получаване на съобщение по ID и един метод POST за задаване на съобщение по ID:
MessageService
Ще определим com.toptal.blog.service
клас в HashMap
. Той ще има достъп до съобщения, съхранявани в нашата система от записи (SOR). В производствено приложение SOR ще бъде нещо като релационна база данни. За простота ще използваме @Service public class MessageService { private ConcurrentHashMap messages = new ConcurrentHashMap(); public String getMessage( Integer id ) { System.out.println( 'Getting data from SOR......' ); return messages.get( id ); } public void setMessage( Integer id, String message ){ messages.put( id, message ); } }
:
http://localhost:8080/EhCacheExample/message/set/1/test_message
Сега, ако експортираме проекта като WAR и го разположим в Tomcat, трябва да можем да зададем съобщение, например „test_message“, за ID = 1, като създадем HTTP POST заявка на http://localhost:8080/EhCacheExample/message/1
След това трябва да можем да получим обратно „test_message“ с HTTP GET заявка на pom.xml
използвах Безсъние като удобен REST клиент, за да направя моя тест.
Сега нека накараме EhCache да работи за нас. Необходими са само няколко бързи стъпки, за да конфигурираме нашия проект да работи правилно EhCache.
llc тип s или c
Добавете зависимостта на EhCache Spring Annotations в Maven’s com.googlecode.ehcache-spring-annotations ehcache-spring-annotations 1.2.0
:
org.springframework.cache.ehcache.EhCacheManagerFactoryBean
Spring има вграден EhCache кеш мениджър, com.toptal.blog.cache.CustomCacheManager
. Това е подходящо за повечето ситуации на кеширане, но открих, че дефинирането на персонализиран кеш мениджър е полезно, защото ми позволява да управлявам кеша или програмно, или с анотации, използвайки същия кеш мениджър. Тази статия се фокусира върху поясненията, но нека продължим напред и да дефинираме персонализиран кеш мениджър, за да бъдем готови в случай, че имаме нужда. Ако предпочитате да се придържате към кеша по подразбиране, можете да пропуснете тази стъпка.
Ще дефинираме новия клас в public class CustomCacheManager extends net.sf.ehcache.CacheManager{ public CustomCacheManager(){ super(); } /* Add your own cache methods here. * * public void myCustomCacheMethod(){ * // your code here * } * */ }
:
springrest-servlet.xml
Активирайте го, като актуализирате ... ...
както следва:
ehcache.xml
И накрая, създайте конфигурационния файл на EhCache src/main/resources
в пътеката на класа. По подразбиране Eclipse ще включва timeToLiveSeconds
в пътя на класа и ние ще поставим файла тук. Този файл е необходим за правилното функциониране на EhCache. Той дефинира имената на кеша и някои свойства на всеки кеш, като например @Cacheable
:
@Cacheable
Сега, с всичко настроено и готово за работа, използването на EhCache трябва да бъде лесна и щастлива работа. Можем просто да добавим getMessage
към метода или класа, които искаме да кешираме. Например добавих MessageService
към @Cacheable( cacheName = 'messageCache' ) public String getMessage( Integer id ) { System.out.println( 'Getting data from SOR......' ); return messages.get( id ); }
метод в http://localhost:8080/EhCacheExample/message/set/1/newMessage
. Това е толкова лесно!
http://localhost:8080/EhCacheExample/message/1
За да проверим дали кешът ни работи, можем да създадем съобщение за ID = 1, като издадем HTTP POST заявка на timeToLiveSeconds
и след това да получим съобщението за ID = 1 няколко пъти, с GET заявки към set message [newMessage] at Sun Dec 06 23:55:39 MST 2015 get message [newMessage] at Sun Dec 06 23:55:42 MST 2015 Getting data from SOR...... get message [newMessage] at Sun Dec 06 23:55:47 MST 2015 get message [newMessage] at Sun Dec 06 23:55:49 MST 2015 get message [newMessage] at Sun Dec 06 23:55:54 MST 2015 Getting data from SOR......
. Както можете да видите в изхода на конзолата по-долу, уеб услугата иска SOR да получи съобщението първия път, когато поискаме съобщението, но не и за следващите две заявки, вместо да върне кешираното съобщение. Защото дефинирахме @TriggersRemove
за да бъде 10, уеб услугата извиква SOR, за да получи съобщението отново след 10 секунди:
setMessage
Сега се наслаждаваме на скоростта и удобството, което кешът ни дава, и EhCache е достатъчно добър, за да се опреснява сам на всеки 10 секунди. Но какво, ако бихме искали да го обновим веднага след актуализирането на нашия SOR? EhCache Spring Annotation предлага getMessage
за премахване на определени ключове от кеша при извикване на анотирания метод. В нашия API за услуга за съобщения кешираното съобщение трябва да бъде премахнато от кеша, когато @Cacheable( cacheName = 'messageCache', keyGenerator = @KeyGenerator ( // method name is not included in cache key to work with @TriggersRemove name = 'HashCodeCacheKeyGenerator', properties = @Property( name='includeMethod', value='false' ))) public String getMessage( Integer id ) { System.out.println( 'Getting data from SOR......' ); return messages.get( id ); } @TriggersRemove( cacheName = 'messageCache', keyGenerator = @KeyGenerator ( name = 'HashCodeCacheKeyGenerator', properties = @Property( name='includeMethod', value='false' ))) public void setMessage( @PartialCacheKey Integer id, String message ) { messages.put( id, message ); }
е наречен. По този начин следващият път a @KeyGenerator
заявката идва, кешът ще извлече нов запис от SOR:
setMessage
Генераторът на ключове се използва от кеш мениджъра за генериране на кеш ключа. Може да се намери списък с предварително дефинирани генератори на кеш ключове тук . По подразбиране, getMessage
консумира както името на метода, така и предадените параметри, за да генерира кеш ключа. Но тъй като искаме includeMethod
метод за генериране на същия ключ като false
и да изтрием кешираната стойност, свързана с този ключ, трябва да използваме само идентификатора на съобщението като ключ и да премахнем името на метода за генериране на ключ. Следователно ние задаваме генератора на ключове setMessage
свойството да бъде @PartialCacheKey
и за двата метода. Също така, тъй като id
има два аргумента, използваме EhCache’s messageCache
анотация на HTTP POST: http://localhost:8080/EhCacheExample/message/set/1/newMessage1 HTTP GET:http://localhost:8080/EhCacheExample/message/1 HTTP POST: http://localhost:8080/EhCacheExample/message/set/1/newMessage2 HTTP GET:http://localhost:8080/EhCacheExample/message/1
параметър, за да се посочи, че той е единственият, който трябва да се използва от генератора на ключове. И накрая, припомнете си, че конфигурирахме специален кеш, set message [newMessage1] at Tue Dec 08 17:53:44 MST 2015 get message [newMessage1] at Tue Dec 08 17:53:47 MST 2015 Getting data from SOR...... set message [newMessage2] at Tue Dec 08 17:53:50 MST 2015 get message [newMessage2] at Tue Dec 08 17:53:53 MST 2015 Getting data from SOR......
, за този тип ресурс, така че използването само на идентификатора за ключа не представлява опасност от конфликти с други типове ресурси.
Сега, ако направим няколко HTTP заявки за съобщението с ID = 1, както следва:
|_+_|
Конзолата ще покаже:
google естествен език API пример
Окончателната структура на проекта изглежда така:
В този пример първо създадохме просто уеб приложение за Spring MVC RESTful. Без да модифицираме дори един ред от съществуващия код на приложението, ние след това безпроблемно интегрирахме EhCache в приложението, използвайки EhCache Spring Annotations. Демонстрирахме, че пролетните анотации на EhCache са лесни за инсталиране (чрез добавяне на зависимостта му Maven) и елегантни за използване (чрез добавяне на пояснения към методите).
Документацията на EhCache може да бъде намерена тук и документацията на EhCache Spring Annotations е тук .
Също така вижте примерния проект, описан в тази статия на GitHub .