[Java lista] Metodusok cachelese

[sashee]

Szia,

az annotaciokat mar nem kell parameterezni, ha belep egy @DbQuery-vel
annotalt metodusba, akkor az osszes cache torlodik es elesedik, mivel
ez ugyis csak olvasni fog. Tehat az egesz felvetes 3 db annotaciot
tartalmaz, nem parameterezhetoek, es csak metodusra tehetoek. Cachelo
DAO-t alkalmazok jelenleg, viszont ehhez kellett irni egy csomo kodot
(megha nagyjabol trivialis is volt), ezert is kezdtem el gondolkodni
altalanos megoldason.

Nem tudtam meg eddig, hogy ezt memoizationnek hivjak, ugylatom nehany
nyelvben megvan ennek a tudomanya is. Ahogy latom javaban proxy-val
megoldhato, azonban en inkabb az adatbaziscachelo reszt tartom
fontosabbnak.

sashee

2011/2/8 Zsombor <gzsombor at gmail.com>:
>
>
> 2011/2/8 sashee <gsashee at gmail.com>
>>
>> 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
>
>
> Szerintem nem annyira praktikus annotációkkal programozni, s egy közepesen
> bonyolult helyzetben is már nehéz lesz generikusan fel annotálni a kódot,
> hogy "ha ez a metódus meghívódik X Y és Z paraméterrel, akkor invalidáld A
> és B és C cache-ben ezt és ezt a kulcs tartományt".
>  Ennél sokkal egyszerűbb, ha a "DAO" réteg elé írsz egy cachelő DAO-t ...
> Persze nem hangzik olyan jól, de gyorsabban kész leszel vele, és könnyebben
> át fogod látni mi miért történik :)
>
> Zs
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>
>