[Java lista] Metodusok cachelese

István Viczián viczian.istvan at gmail.com
2011. Feb. 15., K, 22:57:31 CET


Üdv,

Spring 3.1-nek része lesz, org.springframework.cache package-ben elérhető.

Viczi

2011/2/9 István Viczián <viczian.istvan at gmail.com>:
> Üdv,
>
> Nem tudom mennyire ide vágó, de én ezt láttam:
> http://code.google.com/p/ehcache-spring-annotations/
>
> Valamint a Spring Modules-ban van ilyesmi, erről a Spring in action
> részletesen ír, hogy hogy kell/lehet bekonfigurálni.
>
> Viczi
>
> 2011/2/9 OSTYÁNI Péter <panteros at dev-labs.com>:
>>
>> Szia!
>>
>> Mi ezt használjuk adatbázis lookup táblák(országkód, pénznem, stb..)
>> cachelésére:
>>
>> http://jakarta.apache.org/jcs/index.html
>>
>> ostya
>>
>>
>> On Tue, 8 Feb 2011 22:48:14 +0100, sashee <gsashee at gmail.com> wrote:
>>> Sziasztok,
>>>
>>> ma fejlesztes kozben jutott eszembe egy otlet, es errol kerem a
>>> velemenyeteket. Idonkent belefutok, hogy van nehany tisztan
>>> funkcionalis metodusom, ami kizarolag az argumentumaibol olvas ki,
>>> ebbol csinal valami eredmenyt. Ezt eleg hatekonyan lehet cachelni,
>>> minden bemenetre eleg lenne csak 1x kiszamolni. Pl int
>>> getMeaningOfLine(Life life){...} eseteben mondjuk lenne rajta egy
>>> @Cacheable annotacio, es akkor csak 1x futna le.
>>>
>>> Viszont ez egy eleg ritka dolog, tapasztalataim szerint sokkal
>>> tobbszor fordul elo olyan, hogy adatbazisbol olvasunk ki dolgokat, es
>>> azokkal csinalunk valamit, anelkul hogy modositanank barmit is. Erre
>>> vannak pl JPA tobbszintu cache, viszont azok legfeljebb a query-ket
>>> cachelik, a hozza tartozo java feldolgozast(ami esetenkent eltarthat
>>> egy darabig) azt nem. Tehat a legyeg az lenne, hogy a metodusokra,
>>> amik adatokat kernek le es dolgoznak fel, lehetne tenni pl egy
>>> @DbCacheable annotaciot, ami megintcsak az argumentumok szerint
>>> eltarolja, es ha ujra meghivodik, akkor csak azt adja vissza.
>>> Ertelemszeruen a db valtozhat, ezert a hivo metodusra is kell tenni
>>> mondjuk egy @DbQuery-t, aminek a hatasara torlodnek a cachek, viszont
>>> elesednek is, amig a metodusban van a vegrehajtas. Ha egymasban tobb
>>> igy felannotalt metodus van, akkor persze a legkulso hatasa
>>> ervenyesul. Ertelemszeruen az igy megannotalt metodus nem valtoztatja
>>> szamottevoen a db tartalmat.
>>>
>>> Leginkabb ezt arra tartanam kenyelmes megoldasnak, ha nem igazan lehet
>>> szepen megirni a feldolgozast ugy, hogy azonos adatok ne legyenek
>>> lekerve tobbszor. Ez altalaban megoldhato lenne mas
>>> programstrukturalassal, vagy custom cache osztaly hasznalataval, de ha
>>> ez automatizalhato lenne 2 annotacio hasznalataval, akkor az megiscsak
>>> kenyelmesebb.
>>>
>>> Megvalositas szerint akar aspektusokkal akar talan apt-vel megoldhato
>>> lenne.
>>>
>>> Milyen problemak lephetnek fel ezzel kapcsolatban, valamint van
>>> ilyesmire mar letezo megoldas?
>>>
>>> sashee
>>
>> _______________________________________________
>> Javalist mailing list
>> Javalist at javagrund.hu
>> http://javagrund.hu/mailman/listinfo/javalist
>>
>


További információk a(z) Javalist levelezőlistáról