[Java lista] Metodusok cachelese

sashee gsashee at gmail.com
2011. Feb. 9., Sze, 00:00:16 CET


Szia,

nem, konkretan forditott cacheuritesre gondolok. Tehat nem azt
mondani, hogy ez a metodus modosit a db-n, es ezert a futasa utan ki
kell uriteni a cacheket, hanem azt, hogy ez a metodus nem modosit a
db-n, emiatt minden altala meghivott lekerdezo metodus eredmenyet eleg
csak egyszer kiszamolni.

sashee

2011/2/8 Zsombor <gzsombor at gmail.com>:
>
>
> 2011/2/8 sashee <gsashee at gmail.com>
>>
>> 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
>>
>
> Szia !
>
>  Persze, az adott esetben elhiszem, hogy ilyen egyszerű cache megoldás
> megteszi - azaz egy módosító metódus után az összes cachet üríted (mondjuk
> akkor én nem a DbQuery hanem mondjuk DbUpdate vagy DbUpdater annotációt
> használnék :) ), csak tapasztalataim szerint ennél többre van szükség.
>
> Zs
>
>
>>
>> 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
>> >
>> >
>> _______________________________________________
>> Javalist mailing list
>> Javalist at javagrund.hu
>> http://javagrund.hu/mailman/listinfo/javalist
>
>
> _______________________________________________
> 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