Åpen kildekode Java-prosjekter: Java Caching System

Enterprise Java-spesialist Steve Haines blir med i Open Source Java-prosjektserien denne måneden med en introduksjon til Java Caching System (JCS), en robust løsning for hurtigbufring av bedrift. Steve starter med en rask introduksjon til hurtigbufring, diskuterer kriteriene for å avgjøre om objekter skal bufres, og om applikasjonen din vil ha nytte av en hurtigbuffer. Deretter viser han deg hvordan du konfigurerer JCS og bruker den til å bygge et caching-program.

Java Caching System (JCS) er et robust cache-produkt med åpen kildekode som er utgitt gjennom delprosjektet Apache Jakarta. Den gir standardfunksjonene du forventer av et cache-system, for eksempel hurtigbufring i minnet og algoritmer for selektivt å fjerne objekter fra cachen. Det tilbyr også mer avanserte funksjoner, for eksempel indeksert diskbufring og støtte for distribuerte cacher.

En JCS-cache har en kartlignende struktur der data lagres i cachen som et navn-og-verdipar. JCS partisjonerer hurtigbufferen i regioner. Hver region har sin egen konfigurasjon så vel som sitt eget sett med navn-verdipar. Hver region kan:

Vær forskjellig størrelse
Bli implementert annerledes
Inneholder forskjellige data

De nøklene (navnene i navn- og verdiparene) i en region kan være de samme som nøklene i andre regioner. Dette er viktig fordi det gjør det mulig å opprettholde separate cacher for forskjellige objekter innen samme JVM - og alle definert i en enkelt egenskapsfil.

Åpen kildekode lisenser

Hvert av Java-prosjektene med åpen kildekode som dekkes i denne serien, er underlagt en lisens, som du bør forstå før du integrerer prosjektet med dine egne prosjekter. JCS er underlagt Apache-lisensen; se Ressurser for å lære mer.

Denne artikkelen utforsker JCS ved først å vise deg hvordan du får tak i og installerer den nåværende versjonen. Jeg forklarer deretter hva en hurtigbuffer er, hvorfor du kan bruke en, og om det er den rette løsningen for et bestemt program. Deretter vil du fordype deg i JCS-egenskapsfilen, som er den beste måten å forstå JCS på. Til slutt bygger du et eksempel på hurtigbufring som bruker JCS.

Kom i gang med JCS

Du kan laste ned JCS fra nedlastingssiden til JCS-prosjektnettstedet. I skrivende stund er den siste versjonen 1.3. Last ned den binære distribusjonen (enten som en TAR-fil på Unix-systemer eller som en ZIP-fil på Windows) og dekomprimerer den til en lokal katalog på datamaskinen din.

Roten til installasjonskatalogen inneholder jcs-1.3.jar, som du må legge til i CLASSPATH før du kompilerer og kjører JCS-applikasjoner.

Klassedokumentasjon gullgruve

Gjennom denne artikkelen, så vel som i dine egne uavhengige studier, vil du finne at JCS dokumenter katalog er en uvurderlig ressurs for informasjon om JCS, inkludert API-dokumentasjon. Det robuste Javadoc-dokumentet er din autoritet til å forstå hvordan du bruker JCS-klasser.

Du trenger to avhengigheter:

Commons Logging
Samtidig

Fra Commons Logging, legg til commons-logging.jar til din CLASSPATH.

En hurtig caching-primer

En cache er designet for å holde objekter, vanligvis i minnet, for umiddelbar tilgang for et program. En applikasjon samhandler annerledes med en cache fra måten den interagerer med eksterne lagringsløsninger på. Vanligvis oppnår et program en forbindelse til en database, utfører et spørsmål på tvers av et nettverk og analyserer resultatene når de returneres. En cache vedlikeholder en samling lett tilgjengelige objekter i en robust kartlignende struktur som ikke krever et nettverkssamtal. Enterprise Java-applikasjonsytelsen forbedres eksponentielt når den får tilgang til gjenbrukbare objekter i en cache etter at de er lastet inn fra en database, i stedet for å foreta eksterne databasesamtaler.

Hvis applikasjonen din har et håndterbart antall objekter som ofte er tilgjengelig, kan en cache sannsynligvis forbedre ytelsen. Java-applikasjoner er begrenset av tilgjengelige ressurser i JVM, hvorav det mest verdifulle er minne. Det gir ingen mening å ta minne fra en JVM for å holde på objekter som sjelden er tilgjengelig. Det er sannsynligvis bedre å laste inn et objekt som er tilgjengelig en gang i løpet av noen få timer etter behov, og legge igjen nok ledig minne til andre ressurser. På den annen side er det bedre å laste objekter som er tilgjengelig flere ganger i minuttet - eller til og med flere ganger i timen - i en cache og servere dem fra minnet, i stedet for å ringe et eksternt anrop hver gang objektet er nødvendig. Hvis antallet objekter applikasjonen din ofte bruker, kan håndteres i tilgjengelig minne, er det en god kandidat for hurtigbufring. Men hvis det får tilgang millioner av objekter ofte, så kan det fremdeles være i programmets beste interesse å laste inn objekter etter behov, i stedet for å bruke 75 prosent av en JVM-bunke for å være vert for hurtigbufferen.

Caching versus pooling

Forvirring om skillet mellom cache og basseng kommer ofte frem i diskusjoner om caching. Hvilke gjenstander skal bufres og hvilke gjenstander som skal samles? Svaret ligger i selve gjenstandene. Hvis et objekt opprettholder tilstand, bør det bufres. Statsløse gjenstander bør samles. Som en analogi kan du vurdere to aktiviteter: kjøpe mat i et supermarked og hente et barn fra skolen. Enhver kasserer kan sjekke ut enhver kunde i supermarkedet; det spiller ingen rolle hvilken kasser du får, så kasserere bør samles. Når du henter barnet ditt fra skolen, vil du din barn, ikke noen andres, så barn bør caches.

Ved å ekstrapolere denne ideen til bedriftens Java, bør ressurser som databaseforbindelser og forretningsprosessbønner samles, mens gjenstander som ansatte, dokumenter og widgets bør caches. Det spiller ingen rolle hvilken databaseforbindelse søknaden din får fra en tilkoblingsbasseng - de gjør alle det samme - men hvis du vil gi deg selv en lønnsøkning, er det viktig at du får din ansattes objekt.

Forståelse av JCS-regioner

Å bruke JCS er faktisk ganske enkelt, men du trenger grunnleggende kunnskap om hvordan JCS definerer hurtigbufferegioner og hvordan de kan konfigureres. JCS-egenskapsfilen er det logiske stedet å begynne å forstå JCS. Oppføring 1 viser et eksempel på en JCS-egenskapsfil.

Oppføring 1. En JCS-egenskapsfil (cache.ccf)

# STANDARD CACHE-REGION jcs.default = DC jcs.default.cacheattributes = org.apache.jcs.engine.CompositeCacheAttributes jcs.default.cacheattributes.MaxObjects = 1000 jcs.default.cacheattributes.MemoryCacheName = org.apache.jcs.engine.memory .lru.LRUMemoryCache jcs.default.cacheattributes.UseMemoryShrinker = true jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds = 3600 jcs.default.cacheattributes.ShrinkerIntervalSeconds = 60 jcs.default.cache.cache.cat. elementattributter.IsEternal = falske jcs.default.elementattributes.MaxLifeSeconds = 21600 jcs.default.elementattributes.IdleTime = 1800 jcs.default.elementattributes.IsSpool = true jcs.default.elementattributes.IsRemote = true jcs.default.sement.elementattel # FORDefinert CACHE-REGIONER jcs.region.musicCache = DC jcs.region.musicCache.cacheattributter = org.apache.jcs.engine.CompositeCacheAttributter jcs.region.musicCache.cacheattributes.MaxObjects = 1000 jcs.region.musicCache.cacheattributes. ame = org.apache.jcs.engine.memory.lru.LRUMemoryCache jcs.region.musicCache.cacheattribute.UseMemoryShrinker = true jcs.region.musicCache.cacheattributes.MaxMemoryIdleTimeSeconds = 3600 jcs.region.musicCache.cach.cach.cach.cach.cach.cachs.cach.cach.cach.cach.cach.cach.cach.cach.cach.cach.cach.cach.cach.cach.cach.cache region.musicCache.cacheattributs.MaxSpoolPerRun = 500 jcs.region.musicCache.elementattributes = org.apache.jcs.engine.ElementAttributes jcs.region.musicCache.elementattributes.IsEternal = false # TILGJENGELIG TILBEHØR CACHES jcs.auxiliary.DC = .jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory jcs.auxiliary.DC.attributes = org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributter jcs.auxiliary.DC.attributes.DiskPath = c: / temp jcs.auxiliary.DC .attributes.MaxPurgatorySize = 10000000 jcs.auxiliary.DC.attributes.MaxKeySize = 1000000 jcs.auxiliary.DC.attributes.MaxRecycleBinSize = 5000 jcs.auxiliary.DC.attributes.OptimizeAtRemoveCount = 300000 jcs.auxiliary.DC.attributes.ShutdownSpoolTimeLime

Listing 1 inneholder tre seksjoner:

Standardområdet definerer standardkonfigurasjonen for alle regioner med mindre den overstyres eksplisitt av en av de andre regionene.
Neste er en liste over forhåndsdefinerte (det vil si brukerdefinerte) hurtigbufferegioner, som i dette tilfellet inkluderer musicCache som jeg skal bruke i det kommende eksemplet.
Hjelpecacher definerer hjelpestoffer som kan kobles til en cache-region. Selv om hver hurtigbufferegion må ha ett (og bare ett) minnehjelpemiddel, kan den ha et hvilket som helst antall andre tilleggsutstyr som kan lagre bufrede data. I dette eksemplet oppretter jeg en indeksert diskbuffer, men du kan også definere lateral og fjernkontroll hjelpestoffer. En sideassistent kan replikere bufrede data til andre hurtigbuffere via en TCP-kontakt eller JGroups-protokollstabel. En ekstern hjelp kan replikere data til andre hurtigbuffere via Remote Method Invocation (RMI).

Hver region kan definere cache-attributter i tillegg til elementattributter. Et cache-attributt definerer et konfigurasjonsalternativ for hurtigbufferen, mens et elementattributt definerer et konfigurasjonsalternativ for elementene i hurtigbufferen. Her er et sammendrag av cache-attributtalternativene:

MaxObjects: Dette er maksimalt antall gjenstander som er tillatt i minnet.
MemoryCacheName: Denne egenskapen lar deg definere minnebehandleren som skal brukes som din MemoryCache. Standard minnebehandler implementerer en LRU-strategi.
UseMemoryShrinker: Dette alternativet gjør det mulig for JCS å gjenta periodisk over hurtigbufferen og se etter objekter som kan fjernes (gjenstander som har utløpt eller har overskredet sin maksimale inaktivitetstid). Standardverdien er falsk.
MaxMemoryIdleTimeSeconds: Hvis minnekrymperen er aktivert, forteller denne egenskapen JCS hvor lenge et objekt kan forbli inaktiv før krymperen fjerner det (og spoler det til disk hvis det er opprettet en indeksert diskbuffer). Standardverdien er -1, som deaktiverer dette alternativet.
ShrinkerIntervalSeconds: Hvis minnekrymperen er aktivert, forteller denne egenskapen JCS hvor ofte krymperen skal kjøres. Standardverdien er 60 sekunder.
DiskUsagePattern: Hvis en diskbuffer er aktivert, forteller denne egenskapen JCS hvordan data skal vedvares når minnebufferen er full. Standardverdien er BYTTE, som bare spoler gjenstander til disken når minnebufferen er full. Det andre alternativet er OPPDATER, som fortsetter all data til disk, men bare når data oppdateres. Hvis en JDBC-tilleggsutstyr er definert som en diskbuffer, forblir alle objekter i minnet (til minnet er fullt) og videreføres også til en database, som gir god ytelse og pålitelighet.

Og her er elementattributtalternativene:

IsEternal: Hvis et element er evig, kan det ikke fjernes fra hurtigbufferen fordi det overskrider maksimal levetid. Dette alternativet er som standard ekte.
MaxLifeSeconds: Hvis elementene ikke er evige, definerer dette alternativet maksimal levetid for hvert objekt før det fjernes. Hvis minnekrymperen kjører, fjernes gjenstander av krymperen. hvis ikke, fjernes de når de er tilgjengelige. Dette alternativet er som standard -1, som deaktiverer alternativet.
IsSpool: Dette alternativet definerer om et element kan spoles ut til disken eller ikke. Det er som standard ekte.
IsLateral: Dette alternativet definerer om et element kan sendes til en sidebuffer eller ikke. Det er som standard ekte.
IsRemote: Dette alternativet definerer om et element kan sendes til en ekstern cache eller ikke. Standardinnstillingen er ekte.

I Oppføring 1 opprettet jeg en region som heter musicCache som har opptil 1000 gjenstander i minnet. Minnebehandleren bruker en LRU-algoritme: når hurtigbufferen er full og JCS trenger å gi plass til nye gjenstander, fjerner den gjenstander som ikke nylig har blitt åpnet. Den har minnekrymperen aktivert, og krymperen vil kjøre hvert 60. sekund. Det vil kaste ut gjenstander som sitter inaktiv i mer enn 60 minutter (3600 sekunder.) Elementene er ikke evige, og de kan skrives ut til disken, til en sidecache eller til en ekstern cache.

Merk at IsSpool, IsLateral, og IsRemote innstillingene arves fra standardinnstillingene. Fordi det jcs.region.musicCache element er satt til DC, er det definert ikke bare for å opprettholde en hurtigbuffer i minnet, men også for å bruke den indekserte diskbufferen som tilleggsutstyr. (Egenskapen kan settes til en kommaseparert liste over flere hjelpere.) Diskbufferen er konfigurert til å lagre elementer i c: / temp katalog. (JCS foretrekker skråstrek fremfor tilbakeslag.) De resterende attributtene konfigurerer diskbufferen ved hjelp av en IndexedDiskCacheAttribute gjenstand; du kan lese om disse attributtene i JCS Javadoc.

Bygg en prøvebuffer-applikasjon

Når du har forstått hvordan du konfigurerer JCS, er det enkelt å bygge et caching-program. Søknaden må kunne:

Initialiser hurtigbufferen fra konfigurasjonsfilen
Få tilgang til en region i hurtigbufferen
Legg objekter inn i hurtigbufferen
Hent objekter fra hurtigbufferen
Fjern objekter fra hurtigbufferen

Cachen kan initialiseres enten automatisk eller manuelt. Hvis du navngir konfigurasjonsfilen cache.ccf og legg den direkte i din CLASSPATH (for eksempel root build-katalogen din), og første gang JCS påkalles, finner den filen og initialiseres riktig. Hvis du trenger å lagre konfigurasjonsfilen din andre steder eller gi den en annen navn, kan du bruke org.apache.jcs.utils.props.PropertyLoader's loadProperties () metode for å laste JCS-egenskaper fra en hvilken som helst eiendomsfil.