Open source Java-projekter: Java Caching System

Enterprise Java-specialist Steve Haines tilslutter sig Open Source Java-projektserien i denne måned med en introduktion til Java Caching System (JCS), en robust caching-løsning på virksomhedsniveau. Steve starter med en hurtig introduktion til cache, diskuterer kriterierne for at afgøre, om objekter skal cachelagres, og om din applikation vil have gavn af en cache. Derefter viser han dig, hvordan du konfigurerer JCS og bruger det til at oprette en caching-applikation.

Java Caching System (JCS) er et robust open source-cachingprodukt, der frigives gennem Apache Jakarta-delprojektet. Det giver de standardfunktioner, som du forventer af et cache-system, såsom cache i hukommelsen og algoritmer til selektiv fjernelse af objekter fra cachen. Det tilbyder også mere avancerede funktioner, såsom indekseret diskcaching og support til distribuerede cacher.

En JCS-cache har en kortlignende struktur, hvor data gemmes i cachen som et navn-og-værdipar. JCS partitionerer cachen i regioner. Hver region har sin egen konfiguration såvel som sit eget sæt navn-værdipar. Hver region kan:

Bliv dimensioneret anderledes
Implementeres forskelligt
Indeholder forskellige data

Det nøgler (navnene i par med navn og værdi) i en region kan være de samme som nøgler i andre regioner. Dette er vigtigt, fordi det giver dig mulighed for at vedligeholde separate caches for forskellige objekter inden for samme JVM - og alle defineret i en enkelt egenskabsfil.

Open source-licenser

Hver af de open source Java-projekter, der er omfattet af denne serie, er underlagt en licens, som du bør forstå, før du integrerer projektet med dine egne projekter. JCS er underlagt Apache-licensen; se Ressourcer for at lære mere.

Denne artikel udforsker JCS ved først at vise dig, hvordan du henter og installerer den aktuelle udgivelse. Jeg forklarer derefter, hvad en cache er, hvorfor du muligvis bruger en, og om det er den rigtige løsning til et bestemt program eller ej. Dernæst dykker du ned i JCS-egenskabsfilen, som er den bedste vej til forståelse af JCS. Endelig opbygger du et eksempel på en cache-applikation, der bruger JCS.

Kom godt i gang med JCS

Du kan downloade JCS fra downloadsiden på JCS-projektwebstedet. I skrivende stund er den seneste version 1.3. Download den binære distribution (enten som en TAR-fil på Unix-systemer eller som en ZIP-fil på Windows), og dekomprimeres til en lokal mappe på din computer.

Roden til installationsmappen indeholder jcs-1.3.jar, som du skal føje til din CLASSPATH inden kompilering og kørsel af JCS-applikationer.

Klassedokumentation guldmine

I hele denne artikel såvel som i dine egne uafhængige undersøgelser finder du, at JCS dok bibliotek er en uvurderlig ressource til information om JCS, herunder API-dokumentation. Det robuste Javadoc-dokument er din autoritet til at forstå, hvordan du bruger JCS-klasser.

Du har brug for to afhængigheder:

Almindelig logning
Samtidig

Fra Commons Logging, tilføj commons-logging.jar til din CLASSPATH.

En hurtig caching-primer

En cache er designet til at indeholde objekter, typisk i hukommelsen, til øjeblikkelig adgang for et program. En applikation interagerer forskelligt med en cache fra den måde, den interagerer med eksterne lagringsløsninger. Typisk får et program en forbindelse til en database, udfører en forespørgsel på tværs af et netværk og analyserer resultaterne, når de returneres. En cache vedligeholder en samling af let tilgængelige objekter i en robust kortlignende struktur, der ikke kræver et netværksopkald. Enterprise Java-applikationsydelse forbedres eksponentielt, når den får adgang til genanvendelige objekter i en cache efter indlæsning fra en database, snarere end at foretage eksterne databaseopkald.

Hvis din applikation har et håndterbart antal objekter, der ofte er adgang til, kan en cache sandsynligvis forbedre dens ydeevne. Java-applikationer er begrænset af tilgængelige ressourcer i JVM, hvoraf den mest værdifulde er hukommelse. Det giver ingen mening at tage hukommelse væk fra en JVM for at holde objekter, der sjældent er adgang til. Det er sandsynligvis bedre at indlæse et objekt, der er tilgængeligt en gang hvert par timer, da det er nødvendigt, og efterlade nok ledig hukommelse til andre ressourcer. På den anden side er det bedre at indlæse objekter, der er adgang til flere gange i minuttet - eller endda flere gange i timen - i en cache og servere dem fra hukommelsen snarere end at foretage et fjernopkald hver gang objektet er nødvendigt. Hvis antallet af objekter, som din applikation ofte åbner, kan håndteres i den tilgængelige hukommelse, er det en god kandidat til caching. Men hvis det får adgang millioner af objekter ofte, så kan det stadig være i en applikations bedste interesse at indlæse objekter efter behov i stedet for at bruge 75 procent af en JVM-bunke til at være vært for cachen.

Caching versus pooling

Forvirring om sondringen mellem en cache og en pool opstår ofte i diskussioner om caching. Hvilke objekter skal cachelagres, og hvilke objekter skal samles? Svaret ligger i selve objektenes natur. Hvis et objekt opretholder tilstand, skal det cachelagres. Statsløse genstande skal samles. Som en analogi kan du overveje to aktiviteter: at købe mad i et supermarked og hente et barn fra skolen. Enhver kasserer kan tjekke enhver kunde i supermarkedet; det betyder ikke noget, hvilken kasserer du får, så kasserer bør samles. Når du henter dit barn fra skolen, vil du have det dit barn, ikke andres, så børn skal caches.

Ekstrapolering af denne idé til virksomheds Java skal ressourcer såsom databaseforbindelser og forretningsbehandlingsbønner samles, mens objekter som medarbejdere, dokumenter og widgets skal caches. Det betyder ikke noget, hvilken databaseforbindelse din ansøgning opnår fra en forbindelsespulje - de gør alle de samme ting - men hvis du vil give dig selv en lønforhøjelse, er det vigtigt at du får dit medarbejder objekt.

Forståelse af JCS-regioner

Brug af JCS er faktisk ret simpelt, men du har brug for grundlæggende viden om, hvordan JCS definerer cache-regioner, og hvordan de kan konfigureres. JCS-egenskabsfilen er det logiske sted at begynde at forstå JCS. Liste 1 viser en JCS-egenskabseksempeleksempel.

Fortegnelse 1. En JCS-egenskabsfil (cache.ccf)

# STANDARD CACHE-REGION jcs.default = DC jcs.default.cacheattributter = org.apache.jcs.engine.CompositeCacheAttributter jcs.default.cacheattributes.MaxObjects = 1000 jcs.default.cacheattributes.MemoryCacheName = org.apache.jcs.engine.memory .lru.LRUMemoryCache jcs.default.cacheattributs.UseMemoryShrinker = sand jcs.default.cacheattributs.MaxMemoryIdleTimeSeconds = 3600 jcs.default.cacheattributs.ShrinkerIntervalSeconds = 60 jcs.default.elementattributs.s. elementattributter.IsEternal = falske jcs.default.elementattributter.MaxLifeSeconds = 21600 jcs.default.elementattributter.IdleTime = 1800 jcs.default.elementattributter.IsSpool = sand jcs.default.elementattributter.IsRemote = sand jcs.default.elementattel. # FORUDINDSTILLET 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.MaxObjects = 1000 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.cache region.musicCache.cacheattributs.MaxSpoolPerRun = 500 jcs.region.musicCache.elementattributes = org.apache.jcs.engine.ElementAttributter jcs.region.musicCache.elementattributes.IsEternal = falsk # TILGÆNGELIG HJÆLPER CACHES jcs.auxiliap.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

Liste 1 indeholder tre sektioner:

Standardregionen definerer standardkonfigurationen for alle regioner, medmindre den tilsidesættes eksplicit af en af de andre regioner.
Dernæst er en liste over foruddefinerede (dvs. brugerdefinerede) cache-regioner, som i dette tilfælde inkluderer musicCache som jeg bruger i det kommende eksempel.
Hjælpecacher definerer hjælpestoffer der kan tilsluttes en cache-region. Selvom hver cache-region skal have en (og kun en) hukommelseshjælp, kan den have et vilkårligt antal andre hjælpeenheder, der kan indeholde cachelagrede data. I dette eksempel opretter jeg en indekseret diskcache, men du kan også definere tværgående og fjern hjælpestoffer. En lateral hjælpestand kan replikere dine cachelagrede data til andre caches via et TCP-stik eller JGroups-protokolstak. En ekstern hjælpestation kan replikere data til andre caches via Remote Method Invocation (RMI).

Hver region kan definere cache attributter såvel som element attributter. En cache-attribut definerer en konfigurationsmulighed for cachen, mens en elementattribut definerer en konfigurationsmulighed for elementerne i cachen. Her er et resume af cache-attributindstillingerne:

MaxObjects: Dette er det maksimale antal objekter, der er tilladt i hukommelsen.
MemoryCacheName: Denne egenskab giver dig mulighed for at definere den hukommelsesadministrator, der skal bruges som din MemoryCache. Standardhukommelsesadministratoren implementerer en LRU-strategi.
UseMemoryShrinker: Denne mulighed gør det muligt for JCS at gentage periodisk over cachen og se efter objekter, der kan fjernes (emner, der er udløbet eller har overskredet deres maksimale inaktivitetstid). Standardværdien er falsk.
MaxMemoryIdleTimeSeconds: Hvis hukommelseskrymperen er aktiveret, fortæller denne egenskab JCS, hvor længe et objekt kan forblive inaktiv, før krymperen fjerner det (og spoler det til disken, hvis der er oprettet en indekseret diskcache). Standardværdien er -1, som deaktiverer denne mulighed.
ShrinkerIntervalSeconds: Hvis hukommelseskrymperen er aktiveret, fortæller denne egenskab JCS, hvor ofte krymperen skal køres. Standardværdien er 60 sekunder.
DiskUsagePattern: Hvis en diskcache er aktiveret, fortæller denne egenskab JCS, hvordan data skal opretholdes, når hukommelsescachen er fuld. Standardværdien er BYTTE RUNDT, som kun spoler emner til disken, når hukommelsescachen er fuld. Den anden mulighed er OPDATER, som fortsætter alle data til disken, men kun når data opdateres. Hvis en JDBC-hjælpestandard er defineret som en diskcache, forbliver alle objekter i hukommelsen (indtil hukommelsen er fuld) og videreføres også til en database, som giver både god ydelse og pålidelighed.

Og her er elementattributindstillingerne:

IsEternal: Hvis et element er evigt, kan det ikke fjernes fra cachen, fordi det overskrider dets maksimale levetid. Denne indstilling er som standard rigtigt.
MaxLifeSeconds: Hvis elementerne ikke er evige, definerer denne mulighed den maksimale levetid for hvert objekt, før det fjernes. Hvis hukommelseskrymperen kører, fjernes objekter af krymperen. hvis ikke, fjernes de, når de åbnes. Denne indstilling er som standard -1, som deaktiverer indstillingen.
IsSpool: Denne indstilling definerer, om et element kan spoles ud til disken eller ej. Det er som standard rigtigt.
IsLateral: Denne indstilling definerer, om et element kan sendes til en lateral cache eller ej. Det er som standard rigtigt.
IsRemote: Denne indstilling definerer, om et element kan sendes til en ekstern cache eller ej. Standard er rigtigt.

I liste 1 oprettede jeg en region med navnet musicCache der rummer op til 1.000 genstande i hukommelsen. Dens hukommelsesadministrator bruger en LRU-algoritme: når cachen er fuld, og JCS har brug for at give plads til nye emner, fjerner den emner, der ikke er blevet åbnet for nylig. Hukommelseskrymperen er aktiveret, og krymperen kører hvert 60. sekund. Det vil skubbe ud, der sidder inaktiv i mere end 60 minutter (3.600 sekunder.) Dens emner er ikke evige, og de kan skrives ud til disken, til en sidecache eller til en ekstern cache.

Bemærk, at IsSpool, IsLateralog IsRemote indstillinger arves fra standardindstillingerne. Fordi jcs.region.musicCache element er indstillet til DC, det er defineret ikke kun for at opretholde en cache i hukommelsen, men også for at bruge den indekserede diskcache som hjælp. (Egenskaben kan indstilles til en kommasepareret liste over flere hjælpestoffer.) Diskcachen er konfigureret til at gemme emner i c: / temp vejviser. (JCS foretrækker skråstreg fremad mod tilbageslag). De resterende attributter konfigurerer diskcachen ved hjælp af en IndexedDiskCacheAttribute objekt; du kan læse om disse attributter i JCS Javadoc.

Opbygning af en prøve-cache-applikation

Når du først har forstået, hvordan du konfigurerer JCS, er det nemt at opbygge en cache-applikation. Ansøgningen skal kunne:

Initialiser cachen fra dens konfigurationsfil
Få adgang til en region i cachen
Læg objekter i cachen
Hent objekter fra cachen
Fjern objekter fra cachen

Cachen kan initialiseres enten automatisk eller manuelt. Hvis du navngiver din konfigurationsfil cache.ccf og læg det direkte i din CLASSPATH (såsom din rodbygningsmappe), finder den første gang JCS påkræves, at den finder filen og initialiseres korrekt. Hvis du har brug for at gemme din konfigurationsfil et andet sted eller navngive den anderledes, kan du bruge org.apache.jcs.utils.props.PropertyLoader's loadProperties () metode til at indlæse JCS-egenskaber fra en hvilken som helst egenskabsfil.